NEIL PEARSON . EW LARSON - CF GRAY 2e 


IN PRACTICE 
m 7 p " iv i 3 j ` Tiaa 





Project Life Cycle 


Executing 


Planning 


Closing 


Level of effort 





Scoping the project (including project charter and sign-off) 

Gaining key stakeholder understanding, involvement and backing 

Establishing the project’s governance arrangements (including the change process) 
Scope approvals 


m Project kick-off 


a Establishing the initial project team 
= Developing the detailed Project Management Plan (PMP) and sub-plans for: Scope, 
Time, Cost, Quality, Human Resources, Communications, Risk and Procurement 


=æ PMP approvals 


Building and managing the project team 

Executing the Project Management Plan and all sub-plans for phase/stage 
Stakeholder management and project communications 

Project meetings and action tracking 

Phase/stage reviews and change/progress monitoring 

Deliverable acceptance and sign-off 


Final project handover to the customer and sign-off 
Financial reconciliation and contract closure 

Final project reporting 

Capture of final lessons learned (retrospectives) 

Post Implementation Reviews (PIR) 

Project celebrations and final project communications 
Disbanding the project team 


Project reporting 

Monitoring for changes/variations to the project 

Ensuring ongoing business need and justification for the project 
Quality control and corrective action taking 


Monitor & Control 
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CAPM 
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cl 
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CPI 
CPIF 
CPM 
CSF 

EF 

EP 

EQ 
ERP 

ES 

FFA 
FFP 
FP-EPA 


FPIF 
INVEST 


ITB 
ITT 
KISS 
LF 


As Low As Reasonably Practicable 
Activity-on-Node 

Best Alternative To a Negotiated 
Agreement 

Bill of Materials 

Build, Own, Operate 
Build-Own-Operate-Transfer 
Build, Operate, Transfer 


Certified Associate in Project 
Management 


Critical-Chain approach to Project 
planning and Management 


Configuration Item 
Commercial Off The Shelf 
Cost Plus Award Fee 
Cost Plus Fixed Fee 

Cost Performance Index 
Cost Plus Incentive Fee 
Critical Path Method 
Critical Success Factors 
Early Finish 

Elevator Pitch 

Emotional Quotient 
Enterprise Resource Planning system 
Early Start 

Force Field Analysis 

Firm Fixed Price 


Fixed Price with Economic Price 
Adjustment 


Fixed-Price Incentive Fee 


Independent, Negotiable, Estimable, 
Small, Testable 


Invitation To Bid 
Invitation To Tender 
Keep It Simple, Stupid 
Late Finish 


Also refer to Table 11.2 for a list of EVM acronyms. 


LS 
MBWA 
MoSCoW 


NGT 
NIH 
NPV 
OBS 
OCM 
PERT 


PCI 
PDM 


PIR 
PMIS 


PMP 
PO 
RBS 
RCA 
RFI 
RFP 
RFQ 
RFT 
RM 
RPN 
SL 
SME 
SOAs 
SWOT 


T&M 
Voc 
WBS 
WIIFM 


Late Start 
Management By Wandering Around 


Must have, Should have, Could have, 
Won't have 


Nominal Group Technique 

Not Invented Here 

Net Present Value 

Organisation Breakdown Structure 
Organisational Change Management 


Program Evaluation and Review 
Technique 


Per cent Complete Index 


Precedence Diagram Method 
Technique 


Post-lmplementation Review 


Project Management Information 
Systems 


Project Management Professional 
Project Office 

Risk Breakdown Structure 
Root-Cause Analysis 

Request for Information 

Request for Proposals 

Request for Quotation 

Request for Tender 

Responsibility Matrix 





Risk Priority Number 

Slack 

Subject Matter Expert 
Standing Offer Arrangements 


Strengths, Weaknesses, 
Opportunities, Threats 


Time and Material contracts 
Voice of the Customer 
Work Breakdown Structure 
What's in it for me? 
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Preface 





SINCE YOU ARE READING THIS TEXT, you have made a decision that learning more about project management 
will have a positive impact for you. You are absolutely right! Project management has become an organisation 
wide core competency; nearly every manager, regardless of discipline, is involved in projects. This text is designed 
to provide project managers and prospective project managers with the knowledge and skills that are transferable 
across industries and countries. 

Our motivation for writing this text was to provide students and practitioners alike with a holistic, integrative 
view of project management. A holistic view focuses on how projects contribute to the strategic goals of the 
organisation. The linkages for integration include the process of selecting projects that best support the strategy 
of a particular organisation and that in turn can be supported by the technical and managerial processes made 
available to bring projects to completion. The goals for prospective project managers are to understand the role 
of a project in their organisation and to master the project management tools, techniques and interpersonal skills 
necessary to orchestrate projects from start to finish. 

The role of projects in organisations is receiving increasing attention. Projects are the major tool for 
implementing and achieving the strategic goals of the organisation. In the face of intense, worldwide competition, 
many organisations have reorganised around a philosophy of innovation, renewal and organisational learning to 
survive. This philosophy suggests a structure that is flexible and project driven. Project management has developed 
to the point where it is a professional discipline having its own body of knowledge and skills. Today it is nearly 
impossible to imagine anyone at any level in the organisation who would not benefit from some degree of expertise 
in the process of managing projects. 


AUDIENCE 


This text is written for a wide audience. Although it is aligned to the Australian VET sector training package for the 
Certificate IV and Diploma of Project Management and the Project Management Body of Knowledge (currently in 
its sixth edition), it covers concepts and skills that are used by managers to propose, plan, secure resources, budget 
and lead project teams to successful completion. The text should prove useful to students and prospective project 
managers in helping them understand why organisations have developed a formal project management process 
to gain a competitive advantage. Readers will find the concepts and techniques discussed in enough detail to be 
immediately useful in any project situation. Practising project managers will find the text to be a valuable guide 
and reference when dealing with typical problems that arise in the course of a project. 

Managers will also find the text useful in understanding the role of projects in the missions of their organisations. 
Facilitators of VET Training may use this text as a replacement to course notes, as the text is aligned to and 
covers all subject material at the Certificate IV and Diploma levels. Members of the Project Management Institute 
will find the text is well structured to meet the needs of those wishing to prepare for PMP (Project Management. 
Professional) or CAPM (Certified Associate in Project Management) certification exams. 

The text has in-depth coverage of the most critical topics found in PMI’s Project Management Body of Knowledge 
(PMBOK®). People at all levels in the organisation assigned to work on projects will find the text useful not only 
in providing them with a rationale for the use of project management tools and techniques but. also because of the 
insights they will gain on how to enhance their contributions to project success. 

Our emphasis is not only on how the management process works but, more importantly, on why it works. The 
concepts, principles and techniques are universally applicable. That is, the text does not specialise by industry type 
or sector. Instead, the text is written for the individual who will be required to manage a variety of projects ina 
variety of different organisational settings. In the case of some small projects, a few of the steps of the techniques 
can be omitted, but the conceptual framework applies to all organisations in which projects are important to 
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survival. The approach can be used in pure project organisations such as construction, research and engineering 
consultancy. At the same time, this approach will benefit organisations that carry out many small projects while 
the daily effort of delivering products or services continues. 


CONTENT 


In this Australian edition of the book, we have responded to valuable feedback received from both students and 
teachers. As a result of this feedback, the following changes have been made: 


E Extended the coverage of all ten areas of the sixth edition of the Project Management. Body of Knowledge 
(2017), with a new chapter covering the aspects of project integration management (chapter 6). 


E Further recognition and explanation of other project management methodologies such as Scrum (Agile), 
PRINCE2, I8@21500:2012, APM, Praxis and Lean Six Sigma. 


Anew chapter covering Scrum in greater detail (chapter 3). 
Localisation of the text to the Australian marketplace, including mapping to the VET competency 
framework for the Certificate IV and Diploma of Project Management. 


E Development of a number of additional online resources to provide students and facilitators (teachers) with 
a rich set of content. 


Complete update of content to bring it in line with current project management thinking. 
Coverage of key project management documents (artefacts) typical of most projects managed under a life 
cycle approach. 

E Access to a number of online project management templates to visually display the structure and content of 
such project management documents. 


m Greater consideration of the integrative nature of project management. 


Overall, the text addresses the major questions and issues the authors have encountered over their 60 combined 
years of teaching project management and consulting with practising project managers in domestic and overseas 
environments. 

The following questions represent the issues and problems practising project managers find consuming most 
of their effort: 


What is the strategic role of projects in contemporary organisations? 
How are projects prioritised? 


What organisational and managerial styles will improve chances of project success? 


How do project managers orchestrate the complex network of relationships involving vendors, 
subcontractors, project team members, senior management, functional managers, and customers that affect 
project success? 

What factors contribute to the development of a highperformance project team? 

What project management system can be set up to gain some measure of control? 


How do managers prepare for a new international project in a foreign culture? 


How does one pursue a career in project management? 


Project managers must deal with all these concerns to be effective. All of the issues and problems listed above 
represent linkages to an integrative project management. view. The chapter content of the text has been placed 
within an overall framework that integrates these topics in a holistic manner, and cases and snapshots are included 
from the experiences of practising managers. The future for project managers appears to be promising. 
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Text at a glance 





THIS TEXT IS DESIGNED to provide a holistic integrative view of project management for students and 


practitioners. We want students to get the most from this book, and we realise that. students have different learning 
styles and study needs. We therefore present a number of study features to appeal to a wide range of students 
which are designed to test their knowledge of theory and practical skills. The text also includes a variety of real-life 
case studies and examples to help illustrate the key topics in each chapter. 


v Learning elements Each chapter begins with a 
number of learning elements that map out the important 
topics and learning goals to help guide students 
through the chapter. These Learning elements are 
mapped against the relevant heading level. 





Learning elements 

2A Understand various project management frameworks and recognise which of 
these typically suit what environments, 

2B Understand project life cycle types and when to select one over another, 

2C Achieve a hightevel understanding of PRINCE2. 

2D Achieve a high-level understanding of SO 21500:2012. 

2E Achieve a high-level understanding of Scrum. 

2F Achieve a high-level understanding of Lean Six Sigma. 

2G Achieve a high-level understanding of the APM framework. 

2H__ Achieve a high-level understanding of the Praxis” framework. 





¥ In theory This feature explains a tool or a technique 
widely used in the field of project management. Some of 
them provide a fascinating background to the rationale 
behind the management and teamwork strategies 
described in this book and give an insight into the way 
these strategies are developed and verified. 


IN THEORY The Mc 


tion technique 


v Template At appropriate junctures in selected 
chapters, a template signpost signals a project template 
available. These templates are made available online. 


Compare the NPY results with the payback results. The NPV model is mere realistic because it 
cansiders the time value of money, cash flows and profitability. When using the NPV model, the 
discount rate (retum on investinent er R@T) can differ for dilferent projects. Fer example, the expected 
RO] on strategic prejects is frequently set higher than eperational prejects. Similarly, R@Is can differ 
far riskier versus safer prejects. The criteria for setting the R@] hurdle rate should be clear and applied 
consistently. 








SNAPSHOT FROM PRAC’ 





When Steve Jobs returned te Apple Computer as its CEO 
in 1997. he became strikingly successful in develapng 
a turnaround strategy that develsped new markets and 
increased marketshare t all began win a strictadherence 
te the mesien statement: 


Figure 4.2 An arrai 





sun 


Apple 5 committed te bringing the best persaral 
cemputng experience te students, educators, 
creatve professionals and cansumers around the 
warid thraugh ns innevate hardware, seftware 
and internet effetings. 


The thrust af ing turnaround strategy included mass 
customation and targetng market segments. Apple's 
primary campettive advantage ís that t centrals both the 
hardware and software aspects ef most af its preducts, 
The vs: led wth this streng strategie advantage, ® highquality and innavatye 
allows Appie t affer innovatien in hardware, sofware æ ikh fits most products 
and jaena pljadpgs Menu indir}. siszleajes- were, — 5 = 


Source: Axe 











4 Snapshots from practice A series of short 

case studies illustrating real-life project management 
problems and creative solutions. The snapshots provide 
a fascinating insight into recent projects from Australia 
as well as internationally and give practical examples of 
how the key topics discussed in the text play out in the 
real world context. 


Risk IÐ (RIM): This will be a unique reference number allocated to a particular risk (bear in mind 
(hat a typical preject may fdentit} hundreds of petential risks). 

Risk name: A simple name for the risk. 

Risk dexriplion: A description of the risk that clearly describes the risk in detail. 

Risk culeyory: Typically, each risk category will be the same as the categories ot'risk identitied in 
develeping ine RES, This isa useful way to later filler the Risk Register Tor analysis and reporting 
purpeses. 

Opportunity/threut risk: A classitication of whether the risk presents a 'hreat'er an oppertunity 
to the project, 

Risk source (ciate/person/source:), Records ‘when, where.and by whern’ the risk was tdentitied. 
"his isa usehul reference (ool, because 11 further Infermaton/questiensare raised around the risk, 
either Lhe persen who raised the risk cun be contacted, or the source (a document er otherwise) 
can be relerred to, 


Souree:© 2018 Dr Ne) Pearson 





A in-text highlights This feature depicts the 
content that has been developed exclusively by the 
lead author, Dr Neil Pearson. This content appears 
within his commercial templates (available at www. 
projectmanagementinpractice.world) and reflects real 
world practices, techniques and analysis. 


TEXT AT A GLANCE 


END OF CHAPTER 
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4 Chapter summary Each chapter contains a 
summary of the key points and topics in an easily 
digestible format, perfect for revision or to remind the 
student of the important topics in each chapter. 


v Weblinks Websites mentioned throughout the 
text are listed at the end of each chapter as an easy 
reference guide for students. These sites can be 
explored to undertake additional research and to 
deepen understanding. 


Webli 


inttps/Aweow pm org/learning/torary/linkinggo) folls-programpro ects businessstrategy6672 

httpsyAavww. pr org/learning/Sbrary/linkingportfollo programpro jeckbusinessstrategy6295 | 
inttpsy/Www w.apm.org.uk/body-ofknowledge/p3management/ 

wwwaisccom 

httpsywwworaclecom/ni/applications/primavera/indexntmi | 
https//decisionlens.com 

tts wewpraxttrameworkorg/en/knowledge/projectprogramme-andportiollomanagement 
httpsibrprg/2008/02/closethe gaphetween-projects.1ptml 

https mbrorg/2005/10/the off ce.of strategy management 

ww wbalancedscorecard.org/BSC@asts/About theBajancedScorecard 

‘tps /mororg/product/the-execution premlumiinking strategyto-operatlons for compettweadvantage/2116-HEK. 





s 


v Key terms Within each chapter key terms are 
highlighted the first time they appear. Key terms are 
defined in the text. For added reference, there is a 
comprehensive list of key terms at the end of each 
chapter and further definitions of project management 
terms may be found in the glossary. 





Key terms 


anaytic hierarchy process (AHP)  Imovatjon process project porttoks office PPO) | 


benefit cost atio (ECR) Internal rate of return (IRR) Project Management information, 
Boston Consutting Group (BCG) Investment Business Case Systems (PMISS) 

matre Investments Project Portfolo Management (Pi 
bottom.up approach mpn systems | 
BuspessCase net present value (NPV) project sponsor 
Busness Case ife cyde nominal group technique (NGT) SMARTA | 
current state opportunity cost strategic objectives 
enterprise architecture, technology — pairwge criterion strategiepanning 

roadmaps or biueprints payback mode! topdown approach 
future state partidi management vision | 


implementation gap priority system 


Review questions 


Bescrbeihemapr compenents efa strategc management process. | 
Expin the rob projects play in the deivery ef an organsation’s strategy | 
. Why shouldpreyects be inked te the orgarisaten's Stratege Plan? 


l. The peitielio of projects is typi ly represented by complance. stratege and operatienalpre jects. What impact di 
this classffication have en project sepcton? 


Why does the priority system descrbedinthis chapter requre that tbe open and published? Bees the process 
encourage tottomup intaton cf projects? Does itdeceurage some pregcts? Why? 
Why shouldan organssaten nat rey eny on financial measures to se ect projects? | 


a pene 





4 Review questions These are found at the end 
of each chapter and are designed to get students to 
reflect on the important topics in each chapter ane to 
ensure students have understood them. 


ercises 


4. Using the BCG matrocilustrated in Figure 4.13 review the investments from the list be low. 


a Iovesiment A 5 a new product that hasbeen re pased into the Industry. tseems te be experencng grewth at t: 
tme. 


a investment B has been hanging on, operations have flagged and we are net makng much profit on these pred 





4 Exercises A list of exercise questions is also 
found in each chapter. These test students on more 
specific skills and knowledge that have been covered 
throughout the chapter. Answers to selected exercises 
are provided online. 


Have a leek atMacwords Appie predicians | 

Pups eens marwor gi co uk/news/apple/spple pred Fia ns-29 1825180270. 

1. Chaose ene af the produci seams and dafia hypatieuca|precuctife qye diagram dep F Pg isch stage yau 
Ahmicthe products curenty a ie, Beveipment Growin Manly or Mecine). Ako indcale product releases yau 
Would ke asee, usg your em povate ideas, | 

j 








a Cases Selected chapters contain in-depth case 
studies which are designed to immerse the student in 
detailed, simulated projects and get them thinking about 
the challenges and potential solutions for each unique 
case. Each case comes with a series of exercises andl 
tasks for the student to complete which mimic the 
considerations ane decisions a project manager would 
have to make. 


Learn without Limits 


hat continually adapts to you, delivering precisely 


Higher Pass Rates 


With Connect, you can complete your coursework anytime, anywhere. 
Millions of students have used Connect and the results are in: research 
shows that studying with McGraw-Hill Connect will increase the 
likelihood that you'll pass your course and get a better grade. 


Connect includes animated tutorials, videos and additional 
embedded hints within specific questions to help you succeed. 
The Connect Success Academy for Students is where you'll find 
tutorials on getting started, your study resources and completing 
assignments in Connect. Everything you need to know about 
Connect is here! 


Connect provides you with reports to help you Identify what you 
should study and when your next assignment is due, and tracks your 
performance. Connect’s Overall Performance report allows you to 
see all of your assignment attempts, your score on each attempt, the 
date you started and submitted the assignment, and the date the 
assignment was scored. 





Text overview 





THIS TEXT IS WRITTEN TO provide the reader with a comprehensive, integrative understanding of the project 
management process. The text focuses both on the science of project management and the art of managing 
projects. 


CHAPTER 1 is a general introductory chapter, providing a wide background to the subject of project management. 
Why we do it and what it involves. Chapter 1 sets the scene for all chapters in the text and introduces the concept of 
using a lifecycle approach to project management. The chapter also defines and explains the difference among the 
terms ‘Standards’, ‘Frameworks’ and ‘Methodologies’. Examples of projects undertaken by companies like Tesla 
Motors®, Apple® and how these projects are important to their future. 


CHAPTER 2 introduces a number of project management frameworks and methodologies. Although the bulk 
of this text is based on the Project Management Institute’s Project Management. Body of Knowledge (PMBOK), 
it is important for project managers to have a high level understanding of key frameworks and methodologies 
currently present in the marketplace; and an understanding of the key features each offers. Included in this chapter 
is a discussion on PRINCE2®, Scrum (Agile), Praxis®, APM, ISO 215@@:201 and Lean Six Sigma, in addition to a 
more detailed overview of the PMI’s life cycle approach and the PMBOK sixth edition. 


CHAPTER 3 isa new chapter that provides an extended narrative of the Scrum approach, roles, events andartefacts. 
It includes examples of upto-date techniques and tools commonly experienced in a Scrum project environment. 


CHAPTER 4 focuses on how organisations go about evaluating and selecting projects. Special attention is devoted 
to the importance of linking project selection to the strategic objectives of an organisation. Included in this chapter 
is the preparation and use of the business case prior to project selection and during the life of a project. The chapter 
also considers project prioritisation and portfolio and program management as a backdrop to the selection of 
projects. 


CHAPTER 5 reviews the setting within which most projects exist, that is, the organisation. The different types of 
project structures are introduced, ranging from functional and matrix to projectised. This is supplemented with a 
discussion on the influence of the organisational culture on the project environment. 


CHAPTER 6 is a new chapter that takes the subject of project integration management and outlines the key 
activities critical to ensuring an integrative approach to managing a project. The chapter also includes dotpoint 
sununaries for each knowledge area with examples of integrative activities. 


CHAPTER 7 deals with defining and gaining approval for the scope of the project and the development of the 
project's Work Breakdown Structure (WBS). Included in this chapter is a discussion on the importance of having a 
change process in place from the outset of the project. 


CHAPTER 8 details the challenge of formulating resource, cost and time estimates. The chapter utilises the 
information from the WBS to arrive at a project cost and duration. This is then further extended in CHAPTER 9 and 
CHAPTER 10, where a detailed review of project schedule management and project. cost management is carried 
out. 


CHAPTER 11 brings together the scope, time and cost chapters from a performance and monitoring perspective. 


This chapter introduces the topic of project performance reporting with a focus on Earned Value Management 
(EVM). 


TEXT OVERVIEW 


CHAPTER 12 considers the topic of project quality management. Here the importance of specifying quality is 
discussed (a departure from the phrase ‘fitness for purpose’); along with the discrete activities around ensuring 
Quality Assurance (QA) and Quality Control (QC) is defined and applied to the project environment. 


CHAPTER 13 assesses how resources (human, financial, materials and other) are identified, allocated and managed 
in a project environment. 


CHAPTER 14 takes a look of the sociocultural side of project management, covering aspects such as the role and 
skills of the project manager. The chapter then focuses on the core project team; it combines the latest information 
on team dynamics with leadership skills/techniques for developing a highperformance project team. Included is 
an introduction to servant leadership, how the approach is leveraged in a Scrum environment and its applicability 
to the ‘traditional’ project manager. 


CHAPTER 15 takes a more in-depth look at stakeholders from the identification of stakeholders, to the analysis 
of the stakeholders, through to some of the complexities in managing stakeholders on a dayto-day basis. This 
chapter also covers the importance of understanding organisational change management as a project manager, 
and introduces the topic of stakeholder co-creation—a form of cooperation in which all participants (stakeholders) 
influence the process and the result. 


CHAPTER 16 is concerned with planning and developing a communications strategy for the project, the increasing 
role and significance of stakeholder management; in addition to the identification, scheduling and development of 
communications across the myriad mediums now available to the project manager. The task of managing project 
information systems is also considered in this chapter. 


CHAPTER 17 is all about risk—beginning with the context of risk within which the organisation operates and how 
this influences the project environment. This is followed by an extensive discussion on the components and tools 
used in each part of a mature risk management standard—that of ISO 31000:2018 Risk management—Principles 
and guidelines. 


CHAPTER 18 reviews the procurement aspects of project management. Procurement. activities start from the 
Initiation stage of the project with the identification of longlead time items and large capital items. The Procurement 
Management Plan is introduced along with the different types of tenders and a typical contract negotiation process. 


CHAPTER 19 brings the project life cycle to a close, with a discussion on project closure. Covering aspects of 
financial, human and project reporting. This chapter also takes a more indepth look at lessons learned. 


CHAPTER 20 (online) provides insights into project management as a career. 
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CHAPTER 1 
MODERN PROJECT MANAGEMENT 





Learning elements | 


JA Understand how projects differ from routine operational work. 

4B Develop an understanding of the background to project management. 

4C Understand the difference between a standard, a framework and a methodology. 
4D Understand, at a broad level, the concept of a project life cycle. 


4E Make the link between an organisation’s strategy and the need for projects. i 





In this chapter 


=E 1.1 Introduction 
= 1.2 What is a project? 


1.3 Standards, frameworks and methodologies 





1.4 The importance of project management 


= 1.5 Project management today: A holistic approach 





= Summary 


PART 1 SETTING THE SCENE 


1.1 INTRODUCTION 


This is a good time to be reading an up-to-date text about project management as many business 
leaders and experts have proclaimed that project management is a strategic imperative. Project 
management provides employees with a powerful set of tools that can improve their ability to design, 
plan, implement and manage activities to accomplish specific organisational objectives. But project 
management is more than just a set of tools; it is a results-oriented management style that places 
a premium on building collaborative relationships among a diverse ‘cast of characters’. Exciting 
opportunities await people who are well-skilled in project management! 

The ‘project approach’ has long been the preferred style of ‘doing business’ in the construction and 
mining industries and in government, as well as in big consulting firms. Project management is found 
in all avenues of work in today’s global marketplace. Project teams carry out everything: from port 
expansions, to hospital restructuring, to upgrading information systems. Project teams are creating 
next-generation fuel-efficient vehicles, are developing sustainable sources of energy, exploring 
the farthest reaches of outer space, and ‘delving beneath’ our seas to explore offshore resource 
possibilities. The impact of project management is arguably most profound in the software industry, 
where the new ‘folk heroes’ are those professionals whose Herculean efforts lead to a constant flow of 
new hardware innovations and software products. 

Project management is a discipline that can be applied to all industries, whether the private 
sector, the public sector (government) or not-for-profit organisations. It can be applied to endeavours 
as varied as providing emergency aid (e.g. during Cyclone Yasi, in Queensland) to devising and 
implementing strategies for reducing crime and illicit drug abuse within a city. 

A strong indicator of the demand for project management can be seen in the rapid expansion of 
the Project Management Institute (PMI), a professional organisation for project managers. PMI 
membership has grown from 93 000 in 2002 to more than 500 000 as of 2018 (PMI2018a).See Snapshot from 
Practice: Project Management Institute (PMI), Australian Institute of Project management (AIPM) 
and other key project management bodies for information regarding professional certification in project 
management. 

It is nearly impossible to pick up a newspaper or business periodical and not find something 
about projects! As Figure 1.1 indicates, the value of just seven countries’ infrastructure projects is a 
staggering US$381 billion. As of 2016, the Australian Department of Industry, Innovation and Science 
reported investment in the services and construction, mining and manufacturing industries as valued 
in excess of A$13@ billion (OCE 2016). 

The value of individual projects is also increasing to meet the demands of a growing global 
population; for example, the Sydney Metro Northwest project (due to open in 2019) is estimated at a 
cost of A$13 billion, and the cost of the new London Crossrail project (due to open at the end of 2018) 
stands at UK£15 billion (about A$25 billion at 2018 rates). To meet the demands of such projects, 
the project management discipline is fast entering a new era of even more integrated and complex 
projects. 

The discipline of project management is not without its problems. The Standish Group has tracked 
the management of information technology (IT) projects since 1994. This firm's periodic ‘landmark’ 
reports summarise some of the factors behind the continued need for improved project management 
and the importance of continually learning from past projects, so future projects have smoother 
pathways. 

Looking across the Standish Group's chaos reports for 2011 to 2015 (Table 1.1), it can be seen that 
there was marginal year-on-year resolution of projects (resolution being ‘ontime,’ ‘on-cost’ with a 
satisfactory result). The survey goes on to unpack various dimensions of projects—it is evident that 
the project management discipline has stalled in improving the ‘resolution’ of projects. 

Underneath these figures however, has been a change in the project management approach: a big 
shift from ‘waterfall’ (predictive) project management, towards an Agile approach. Table 1.2 indicates 
this shift. Note the success rates of the Agile approach over Waterfall. 
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Figure 1. 
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Table 1.1 Information technology project success (%), 2011-15 


2011 2012 2013 2014 2015 


Successful 29 27 31 28 29 
Challenged 49 56 50 55 52 
Failed 22 17 19 77 19 


Source: Adapted from The Standish Group, wwwstan@ishgroup.com (data from various Standish Group sources sighted ane referenceel) 


Table 1.2 Waterfall versus Agile approaches (%), 2011 and 2015 


2012 2015 
Waterfall [Agile  ě | Waterfall Agile 
14 42 


Successful 12 39 
Challenged 57 49 56 52 
Failed 29 9 32 9 


Source: Adapted from The Standish Group, wwwstan@lishgroup.com (data from various Standish Group sources sighted ane referenceel) 


Closer to the Australian market are reports from Blake Dawson indicating current trends in scoping 
issues in the Australian construction and infrastructure industry. Survey responses and interviews 
revealed the fellowing key findings: 


@ ahigh prevalence of deficient scoping in Australian construction and infrastructure projects (52%) 


Em scoping inadequacies being discovered far too late and the consequences of poor scoping are 
‘significant’ (64%) 


m cost overruns (61%) 
@ delayed completion (57%) 
@ disputes (30%) (Dawson 2008, p. 7). 
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The Standish Chaos Report (2014) confirms that time has not improved many issues encountered 
in managing projects (Table 1.3). 


Table 1.3 Project ‘challenged’ factors 


1995 2014 


f 
. Lack of user involvement 


. Lack of resources 

. Unrealistic expectations 

. Lack of executive support 

. Changing requirements and specifications 
. Lack of planning 

. Didn’t need it any longer 

. Lack of IT management 


Incomplete requirements 


. Lack of user input 

. Incomplete requirements and specifications 
. Changing requirements and specifications 

. Lack of executive support 

. Technology incompetence 

. Lack of resources 

. Unrealistic expectations 

. Unclear objectives 

- Unrealistic time-frames 


OO WN OW AWN 
ODOOAN DO AWN = 


. Technology illiteracy . New technology 


Source: Adapted from The Standish Group, www.stanalishgroup.com (data from various Standish Group sources sighted and referenced) 


On the flip side, the Standish Group has reported (through its chaos reports) some project success 
factors (Table 1.4). 


Table 1.4 Factors of project success 


1994 2012 2016 


1. User involvement 1. Executive support 1. Executive sponsorship 

2. Executive management support 2. User involvement 2. Emotional maturity 

3. Clear statement of requirements 3. Clear business objectives 3. User involvement 

4. Proper planning 4. Emotional maturity 4. Optimisation 

5. Realistic expectations 5. Optimising scope 5. Skilled resources 

6. Smaller project milestones 6. Agile process 6. Standard architecture 

7. Competent staff 7. Project management expertise 7. Agile process 

8. Ownership 8. Skilled resources 8. Modest execution 

9. Clear vision and objectives 9. Execution 9. Project management enterprise 
10. Hard-working, focused staff 10. Tools and infrastructure 10. Clear business objectives 


Source: Adapted from The Standish Group, www.stanglishgroup.com (data from various Standish Group sources sighted and referenced) 


Professional project managers will regularly review these types of reports and will subscribe to 
industry journals and publications to learn from the project profession's wider context (and from more 
focused industry reports, if these are available). 

As Tables 1.1 to 1.4 suggest, the need to elevate performance offers a challenge to the project 
management profession. Many people who excel at managing projects never actually hold the title of 
‘project manager’. This includes accountants, lawyers, administrators, scientists, contractors, public 
officials, teachers and community advocates—whose success depends on being able to lead and 
manage project work. For them, project management is not a title but a critical job requirement. It is 
hard to think of a profession or a career path that could not benefit from sound project management. 

The skillset required in project management is transferable across many sectors, industries, 
businesses and professions. Project management fundamentals are universal: the same project 
management methodology used to develop a new product can be adapted to create new services, 
organise events, refurbish ageing operations (and so forth). In a world where it is estimated that 
each person is likely to experience three to four career changes over the course of their professional 
working life, being able to manage projects is a talent worth developing! 

The significance of project management is also evident in the classroom: 20 years ago, major 
universities offered one or two classes/courses in project management (primarily for engineers). 
Today, most universities offer several project management courses that are geared towards not just 
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engineers, but also business students majoring in marketing, management. information systems and 
finance, as well as students from other disciplines, such as oceanography, health sciences, earth 
sciences and the liberal arts. Students often find that their knowledge of project management provides 
them with a distinct advantage when it.comes time to seek employment. More and more employers are 
looking for graduates with project management skills. RMIT University describes how qualifications 
in project management may help to ‘future-proof’ students’ careers (Johnson 2016). 

The logical starting point for developing project management skills is to gain an understanding of 
its unique features. 

This text aligns with the Australian Skills Quality Authority (ASQA) qualifications, Certificate 
IV in Project Management (BSB41515) and the Diploma in Project Management (BSB51415). ASQA is the 
national regulator for Australia’s vocational education and training (VET) sector. VET enables students 
to gain qualifications for many types of employment, from trade to business and managerial qualifications. 
Further detail on ASQA is at www.asqa.gov.au. For further information on training programs (including 
project management training and qualifications) and to search for government-approved training providers 
(known as registered training organisations—RTOs), visit http://training.gov.au. 

One of the authors, Dr Neil Pearson, also offers a five-day project management ‘boot-camp’ 
covering a large amount of content from this text. Training can act as springboard to the successful 
management of projects and offers a great revision opportunity for PMI certification, or the VET 
Certificate IV and Diploma. For information, visit: www.projectmanagementinpractice.world. 


SNAPSHOT FROM PRACTICE Project Management Institute (PMI), 


Australian Institute of Project Management (AIPM) and other key project 
management bodies 





The Project Management Institute (PMI) (www.pmi.org) was 
founded in 1969 as an international society for project 
managers. Today, the PMI has members from more than 125 
countries, with a total membership in excess of 500 000. PMI 
professionals work in almost every major industry, including 
aerospace, automotive, business management, construction, 
engineering, financial services, information technology, 
pharmaceuticals, health care and telecommunications. 

The PMI offers an industry-recognised certification for 
project managers: the Project Management Professional 
(PMP). This is available only to someone who has sufficient 
documented project experience, agrees to follow the 
PMI Code of Professional Conduct and demonstrates 
mastery of the field of project management by passing 
a comprehensive examination. The number of people 
earning PMP status has grown dramatically in recent 
years. In 1996 there were fewer than 3000 certified 
project management professionals. By the end of 2017, 
there were more than 790 000 PMPs across the globe. 

Being required to pass the PMP (or an equivalent 
industry+ecognised exam/certification) appears to be 
becoming a mandatory standard for project managers. 
Some companies now require that all their project 
managers are PMP certified. Numerous job postings 
now indicate that applications will only be accepted from 
project managers holding an industryrecognised project 





management certification (and/or qualification). Being 
PMP-certified therefore potentially offers candidates a 
‘positive leveraging point’ in today’s marketplace. 

The PMI also offers other certifications, such as Certified 
Associate in Project Management (CAPM). CAPM is designed 
for project team members and entry-level project managers, 
as well as qualified undergraduate and graduate students 
whowant a credential that identifies their comprehension and 
competency in the project management body of knowledge. 
CAPM does not require the level of extensive project 
management experience thatis associated with the PMP. 

In Australia, the primary professional body for project 

managers is the Australian Institute of Project Management 
(AIPM) (www.aipm.com.au). Like the PMI, it has practice- 
based certification based on three levels of competency: 
the Certified Practicing Project Administrator (CPPA), which 
is comparable to the PMI's CPA; the Certified Practicing 
Project Manager (CPPM), which is comparable to the 
PMI’s PMP; and the Certified Practicing Project Director 
CPPD), which is comparable the PM's PgMP (Program 
Management Professional) certification. 
If certification is required that has global recognition, 
project managers can seek certification through the 
nternational Project Management Association (IPMA) 
www.ipma.world). IPMA has a network of member 
associations across 50+ countries. 





PART 1 SETTING THE SCENE 


Table 1.5 indicates some of the key qualifications and certifications found across the globe. 


Table 1.5 Key qualification and certifications, global 








Role | Qualification | Certifications 
Australian AIPM PMI (Project IPMA Best Scrum/Agile Praxis (open Lean Six Sigma 
VET sector (Australian Management (International Management source (International 
Institute Institute) Project Practice project Association 
of Project Management Management for Six Sigma 
Management) Association) approach) Certification— 
IASSC) 
Project Certificate IV CPPP CAPM (Certified IPMA Level PRINCE2 Various Praxis Yellow Belt 
officer/ (Certified Associate D (Certified Foundation Foundation 
coordinator Practicing in Project Project 
Project Management) Management 
Practitioner) Associate) 
Project Diploma CPPM PMP (Project IPMA Level PRINCE2 PMI-ACP Praxis Green Belt 
manager/ (Certified Management C (Certified Practitioner (PMI-Agile Practitioner Black Belt 
senior Practicing Professional) Project Certified 
project Project Manager) Practitioner) 
manager Manager) IPMA Level PRINCE2 
CPSPM B (Certified Agile 
(Certified Practicing Scrum 
Practising Senior Master 
Senior Project Project Scrum 
Manager) Manager) Product 
Owner 
Senior Advanced CPPD PgMP (Program IPMA Level MSP Black Belt 
program/ diploma (Certified Management A (Certified Practitioner Master Black 
portfolio Practicing Professional) Project (Managing Belt 
manager Project PfMP (Portfolio Director) Successful 
and/or Director) Management Programs) 
program/ CPPE Professional) Advanced MSP 
portfolio (Certified Also P30 
director Practising 
Portfolio 
Executive) 
Maturity Project OPM3® P3M3® Praxis 360° 
assessment Managed (Organizational (Portfolio, capability 
Organisation Project Program, assessment 
(award-based) Management and Project 
Maturity Model) Management 
(https://www Maturity Model) 
-pmi.org/ (See www 
learning/library/ .P3m3- 
grow-up- officialsite.com) 
already-opm3- 
primer-8108) 


1.2 WHAT IS A PROJECT? 


What do the following headlines have in common? 


Commonwealth Games. 


1000-acre wind farm to replace a coal-fired power station. 


The world’s largest lithium battery to be built in 100 days. 


Free wifi to be made available in public parks and in bus, train and tram stations. 


@ Shopping mall to be constructed—replacing 40-yearold city ‘eyesore’ buildings. 


City receives stimulus funds to expand its light rail system after winning the bid to hold the next 
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The answer is that all ef these events represent prejects. 

The general definition of a project would include such 
vocabulary as ‘temporary’ and ‘unique’, with the aim of producing a 
product, service or result. (PMI, 2017) 

As for most organisations’ efforts, the major goal of a project is 
to satisfy a customer’s need. Yet beyond this fundamental similarity, 






the characteristics of a project differ from other endeavours of the 
organisation. The five major characteristics of a project are: 


1. an established objective 


2. a defined life span, with a defined beginning and end (i.e. it is 
temporary) 


Shutterstock/Taras Vyshnya 


3. usually, the involvement of several departments and/or stakeholders 
4. typically, doing something that has never been done before (unique) 


5. specific time, cost and performance (scope) requirements. 


The first characteristic pertains to how projects have a defined objective. For example, this may 
be to construct a 12-storey apartment complex by 1 January or to release Version 2.0 of a software 
package as quickly as possible. This singular purpose is often not present in daily ‘business as usual’ 
where workers perform repetitive operations each day. 

The second characteristic comes into play because, as there is a specified objective, the project will 
have a defined endpoint (this differs in nature from the ongoing duties and responsibilities of regular 
work). In many cases, individuals will move from one project to the next (as opposed to staying in one 
job). For example, after helping to install a security system, a telecommunications engineer may be 
assigned to commission a telephone switch. 

Third, unlike much organisational work that is often segmented according to functional 
departments, projects typically require the combined efforts of a variety of specialists from across 
multiple departments of a business. Instead of working in separate offices under separate managers, 
project participants (whether they be engineers, financial analysts, marketing professionals or quality 
control specialists) will work closely together under the guidance of a project manager to complete 
the work as one project. 

The fourth characteristic of a project is that it is nonroutine and has some unique elements. This 
is not an issue but a matter of degree. A project may accomplish something that has never been done 
before, such as building a new type of hybrid (electric/petrol) vehicle, or returning rocket fuel tanks to 
earth for reuse on another mission. Both examples would typically require solving previously unsolved 
problems and potentially applying breakthrough technology. On the other hand, even small projects 
involving established sets of routines and procedures will require some degree of customisation that 
makes them ‘unique’. For example, the refit of one floor of an office would likely be different from the 
refit of another floor; there may be different requirements from the fitout. (office space vs. meeting 
rooms vs. training rooms), different stakeholders, different budget, and so on. 

Finally, specific time, cost and performance requirements bind projects. Projects are evaluated 
according to the accomplishment of scope, cost and time. These triple constraints impose a higher 
degree of accountability than is typically found in many jobs. These three also highlight one of the 
primary functions of project management, which is balancing the trade-offs between time, cost and 
performance (scope), while ultimately satisfying the customer (quality). 


1.2.1 What a project is not 

Projects should not be confused with everyday work (operational activity). A project is not routine, 
repetitive work! Ordinary daily work typically requires doing the same or similar work over and 
over, while a project is done only once and a new product or service will exist when the project is 


PART 1 SETTING THE SCENE 


completed. Examine Table 1.6, which compares routine work and projects. Recognising this difference 
is important because all too often resources can be used up on daily operations that may not contribute 
to longer range organisational strategies that require innovative new products. 


Table 1.6 Comparison of routine (operational) work with project work 


Routine (operational) work Projects 


Entering expense claims into an accounting system Constructing a house 

Responding to a customer service enquiry Relocating a department to anew office building 

Attaching price tags to sales inventory before they are Extending a railway line by 5 km to reach a new suburb 

Place on the shop floor 

Assembling the components of an Apple iPhone® Designing a new digital TV leveraging developments in 
OLED technology 

Analysing management reports to make operational Installing RFID smart tags to allow scan-free checkout 

decisions and payment at a large supermarket 

Carrying out team members’ performance reviews Building a new state-of-the-art hospital in a large city 

Supervising a hospital ward Building a large battery resource to protect the energy 


supply of a region 


1.2.2 ‘Program’ versus ‘project’ 


In practice, the terms ‘project’ and ‘program’ can cause confusion. They are often used synonymously. 
A program is a group of related projects designed to accomplish a common goal over an extended 
period of time to realise a greater set of benefits than a single project could achieve. Each project 
within a program has a project manager. The major differences lie in scale and time span. 

A program is generally defined as a collection of projects brought together to deliver a greater 
benefit than projects could have delivered individually (i.e. the sum is greater than the parts). 
Management of a program and its component projects should: 


Æ be consistent with the organisation's strategy 
enable the program's delivery 


ensure that parts (e.g. schedule, resources, scope) are managed in such a way as to ensure the 
program has the best outcome 


consider risk holistically 
take into account assumptions, constraints and conflict across the whole program 


control upstream and downstream dependencies 


occur under the control of standard governance and program management office. 


1.2.3 ‘Program’ versus ‘portfolio’ 


Just as there is a clear difference between a project and a program, the same is true for portfolios. 
Portfolios provide an overarching umbrella for an organisation to manage all investment activity, 
which may be managed as a mix of programs and/or major projects and operations. A portfolio is a 
true mix of ‘investment’ activity designed to ensure business as usual and investment opportunities 
are blended, to not only keep the organisation running but also to innovate and extend. 

Program management is the process of managing a group of ongoing, interdependent, related 
prejects in a coordinated way to achieve strategic objectives and defined business benefits. For 
example, a pharmaceutical organisation could have a program for working towards curing cancer. 
The cancer research program includes and coordinates all cancer research projects that continue 
over an extended time horizon. Coordinating all cancer research projects under the attention of a 
cancer research team provides benefits not available from managing the projects individually. This 
team also oversees the selection and prioritising of cancer research projects that are included in their 
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special ‘cancer research’ portfolio. Although each project retains its own goals and scope, the project 
manager and team are also motivated by the higher program goal. Program goals are closely aligned 
to the organisation's strategic goals. This link is important, as the results of achieving a program will 
move the organisation further towards achieving its strategic goals. 


1.3 STANDARDS, FRAMEWORKS AND METHODOLOGIES 


The terms ‘standards’, ‘frameworks’ and ‘methodologies’ appear frequently throughout this text (and 
in other resources such as PMBOK). Noting the difference between these terms helps to determine the 
implied level of ‘flexibility’ or ‘rigidity’ of the approach being discussed. 


1.3.1 Standard 


The Cambridge Dictionary definition of a standard is ‘a pattern or model that is generally accepted: 
This pregram is an industry standard fer cem puters’ (Cambridge Dictionary n.d.). ISO's definition is 
a ‘document, established by a consensus of subject matter experts and approved by a recognized body 
that provides guidance on the design, use or performance of materials, products, processes, services, 
systems or persons’ (ISO n.d.). 


E The PMI publishes A Guide te the Preject Management Bedy ef Knewledge (PMBOK) (along with 
other practice standards) to guide a project manager in the management of projects. PMBOK is a 
recognised standard with the American National Standards Institute (ANSI/PMI 99-001-2017). 


E The IPMA publishes a competency baseline: a standard against which to accredit the skill level of 
various project management roles. 


m ISO 21500:2012 is a standard for project management, described as ‘Guidance on project 
management’ (https://www.iso.org/standard/50003.html). 


1.3.2 Framework 


The Cambridge Dictionary definition of a framework is ‘a system of rules, ideas, or beliefs that is used 
to plan or decide something: a legal framewerk fer reselving disputes’ (Cambridge Dictionary n.d.). 


E Scrum is a framework: The Scrum Guide states that ‘Scrum is a framework for developing and 
sustaining complex products’ (Schwaber & Sutherland 2013). 


E The PMI promotes the PMBOK Guide as a framework for managing a project (it is also an ANSI 
standard). 


m ISO 31000 Risk Management offers a framework for managing organisational risks (it is also a 
standard). 


m ISO 21500:2012 Guidance on Project Management contains a high-level framework for the 
management of projects (it is also a standard). 


A framework allows you to be loose and have a degree of flexibility (i-e., permitting some ‘poetic 
licence’ over how it is applied). 


1.3.3 Methodology 


The Cambridge Dictionary definition of methodology is ‘a system of ways of doing, teaching, 
or studying something: The methedelegy and findings ef the research team have been criticized’ 
(Cambridge Dictionary n.d.). 

m PRINCE2 is a methodology (albeit tailoring is considered!). 


E XP, or eXtreme programming, is considered a methodology. 
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m Agile DSDM would be considered a methodology, as it has a defined (prescriptive) method of 
approaching the management of a project in an ‘agile’ manner. 


A methodology is different from a framework as a methodology means there has to be a certain 
(more defined) way of carrying out something. 

The above definitions are provided to assist the reader in determining the degree of rigidity in the 
approaches that are further described in later chapters. 


1.3.4 Project life cycle 
Another way of illustrating the unique nature of project work is the project life cycle. Some project 
managers find it useful to use the project life cycle as the cornerstone for managing projects. The life 
cycle recognises that projects have a limited life span and that there are predictable changes in the 
level of effort and focus over the life of the project. There are a number of different. life cycle models in 
project management literature. Many are unique to a specific industry or type of project. For example, 
a new software development project may consist of five phases: definition, design, code, integration/ 
test and maintenance. A generic cycle based on PMBOK is depicted in Figure 1.3. 

The project life cycle typically passes through four phases: Initiating, Planning, Executing and 
Closing. The starting point begins the moment the project is given the go-ahead. Typically, project 
effort starts slowly, builds to a peak, and then declines as the project is delivered to the customer. 


1l. Initiating phase: Specifications of the project are defined, project objectives are established and 
agreed, teams start to form, and major responsibilities are assigned. 


2. Planning phase: The level of effort increases, and plans are developed to determine what the project 
will entail, when it will be scheduled, who it will benefit, what quality level should be maintained, 


Figure 14.3 Projec 





Executing 


Planning 


Closing 


Level of e“ort 


Monitor and Control 








Start Time End 
Initiating Planning Executing Closing 
1. Definition of 1. Development 1. Change management 1. Financial closure 
project scope of the project 2. Quality control 2. Final project 
2. High-level budgets management plan 3. Project reporting reporting 
3. Indicative timeframe 2. Detailed schedules 4. Delivery of outcomes 3. Final handover to 
4. Project organisation 3. Detailed budgets and outputs customer 
5. Establish project 4. Resourcing 5. Contract management 4. Lessons learned 
charter 5. Risk analysis 6. Team management 5. Release of 
6. Quality definition 7. Stakeholder resources 
7. Communication management 
planning 


8. Planning procurement 
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what the budget will be, what risks there might be, how the project will be communicated, what is to 
be procured, and how resources will be assigned and managed (to name but a few activities). 


3. Executing phase: The agreed project plans are executed. This is where a major portion of the 
project work takes place—both physical and mental. The product, service or result is produced 
(e.g. a bridge, a report, a software program). Time, cost and specification measures are used for 
control—to check whether the project is on schedule, is within budget, and is meeting specifications. 
What are the forecasts of each of these measures? What revisions/changes are necessary? 


4. Closing phase: Closing includes three key activities: delivering the project’s product, service 
or result to the customer, redeploying project resources, and conducting a post-project 
review. Delivery of the project might include customer training and transferring documents. 
Redeployment usually involves releasing project equipment/materials to other projects and 
finding new assignments for team members. Postproject reviews include not only assessing 
performance, but also capturing lesson slearned. 


Although not a phase in its own right, there is an overarching expectation that the project will 
be carefully monitored and controlled throughout its life cycle. One key process commonly applied 
during monitoring and controlling a project is change (or variation) management. This process is 
defined at project initiation and applied throughout the life of the project for changes to any aspects 
of the project, such as changes to the scope of the project, addition of costs not previously identified, 
or even slippage of work activities. 

In practice, the project life cycle is used by some project groups to depict the timing of major tasks 
over the life of the project. For example, the design team might plan a major commitment of resources 
in the Initiating phase, while the quality team would expect their major effort to increase during the 
Executing phase of the project life cycle. Because most organisations have a portfolio of projects 
taking place concurrently, each at a different phase of each project’s life cycle, careful planning and 
management at the organisation and program/project levels are imperative. 


SNAPSHOT FROM PRACTICE Project management in action 





Businesses thrive and survive based on their ability to 
manage projects that produce products and services that 
meet market needs. Below is a small sample of projects 
that are important to their company’s future. 


Company: Tesla 


Project: Hornsdale Power Reserve 
(online battery), South Australia 


This is a 100-MW power reserve stored in the largest (as of 
2018) lithium battery in the world. Located in South Australia, 
at the Hornsdale Wind Farm, the Hornsdale Power Reserve 
(online battery) can (within fractions of a second) ‘kick into 
action to cover peaks in electricity demand, or provide safety 
in supply should a more traditionally fuelled power plant(s) 
fail. The project was constructed by Tesla within 100 days 
(after receiving regulatory approval), completing in December 
2017. The project proved to be of interest around the world 
not only because it pertained to the world’s largest lithium 





@ NEON 


Hornsdale Power Reserve 


Company: Korean Midland Power Co. 
Project: World’s largest tidal turbine farm, South 


battery, but also because Tesla's CEO claimed the battery 
would be handed over free if the project was not delivered to 
its deadline. (httos://nornsdalepowerresetve.com.au) 


Korea 


Korean Midland Power Co. signed an agreement with 
Lunar Energy, Britain's leading tidal power company, to 


(Continued) 
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build a colossal 300-turbine field in the Wando Hoenggan 
waterway off the South Korean coast. The $800 milion 
plus project provided 300 MW of renewable energy, 
enough to power 200 000 homes. The project entailed 
installing a series of 18-metre-high tidal turbines in deep 
ocean water. A 1-MW pilot plant was installed first to 
evaluate the environmental impact before the full-blown 
turbine was allowed. The ecological impact was much less 
than that of conventional tidal barges, which destroy bird 
habitats and hinder the passage of migratory fish such 
as salmon and eels. The project completed successfully 
in 2011. 


Company: Apple Inc. 


Project: Fourth generation Apple watch 


Apple is reported to be developing the fourth generation 
of its ‘smart’ watch that will integrate advanced health 
functions. Whether the marketplace is ready for another 
industry attempt at integrating watch technology with big 
data and analytics to ‘watch over’ the health of individuals 
remains to be seen. The persistent, and often invasive, 
use of technology in every aspect of daily life may be ata 
turning point—but which way will it go? 


Company: Crossrail 


Project: Elizabeth line construction, London, 
England 


This is a massive tunnel project to construct 42 km of new 
underground tunnels (spread across the heart of London) 
to provide a new ‘Elizabeth line,’ connected to the London 
Underground. At GBP£14 billion it is one of Europe's 
largest infrastructure projects. Starting construction in 
2012, its operations are being phased, with the first 
connectivity made operational in 2017 and full operations 
being planned for 2019 (at which point, the line will be 
transporting about 200 million passengers annually!). 
Crossrail can definitely be categorised as a large, complex 
project. (More information at www.crossrail.co.uk.) 


Company: Brisbane Airport Corporation 


Project: Brisbane’s New Runway, Queensland, 
Australia 


At A$1.35 billion, the 3300-m second runway will take 
around eight years to build. It was started in 2014 and 
completion is not anticipated until 2020. It has been 
built on 360 hectares of swampland that is parallel to 
the existing main runway. Built to cater for the expected 
increase in flights—from 227 000 in 2015 to over 360 000 
in 2025—the runway's capacity will rival that of the Hong 
Kong and Singapore airports. By 2035, the runway 
project is anticipated to have created around 7800 local 
jobs, delivering a local economic benefit of circa A$5 





billion annually. (More information at www.bone.com.au/ 
corporate/pne-major-pro jects/brisbanes-new-runway.) 


Company: Apple Inc. 
Project: Apple Park, California, United States 


Apple Park will act as the campus headquarters for 
12000 employees. It is a unique ‘space-ship-like’ 
building, and its construction, design and operation are 
environmentally considerate. The massive 66-hectare 
site had proposed costs that came in at US$500 million. 
By 2011, these were raised to US$3 billion and, as of 
2017, the estimated cost of completion had risen to circa 
US$5 billion. This goes to show that even with best project 
estimates, costs can (and almost always will) overrun! A 
lot of the costs have been attributed to the development 
of ecofriendly features, such as landscaping (7000 
trees), rooftop solar panels, and water recycling. (More 
information at https://www.macworld.co.uk/feature/apple/ 
complete-guide-apple-park-3489704/) 


Shutterstock/Uladzik Kryhin 


Apple headquarters 


Company: SingHealth 
Project: National Cancer Centre, Singapore, 
New Building 


As people live longer and many lifestyles and 
environments remain unhealthy, cancer incidence 
increases. SingHealth is involved in the state-of-the- 
art construction of a new dedicated building and 
resources to meet forecast demand for such facilities. 
The building is a ‘patient-centric design’, with access 
and connections to existing site resources. It will 
house not only advanced therapy centres (based on 
proton therapy), but also research and innovation 
hubs. The project demonstrates a commitment to the 
needs of the patient (the customer) in all aspects of 
design through to operations. (More information at 
https://www.necs.com.sg/AboutUs/OurFacilities/Pages/ 
NewNCCSBuildingProtonTherapyCentre.aspx.) 
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This life cycle will form the basis of the framework that will be used throughout this text. Chapter 2 
provides further detail on the PMBOKbased project management life cycle, with each subsequent. 
chapter targeting a specific area of knowledge within the project management life cycle. 


1.3.5 The project manager 


In some ways, project managers perform similar functions to generic managers, because they plan, 
schedule, motivate and monitor work. However, what makes them dissimilar is the fact that they 
manage temporary, non-repetitive activities to complete a fixed duration project. Unlike functional 
managers who take over existing operations, project managers create a project team where none 
previously existed. They must decide ‘what’ and ‘how’ things should be done, instead of simply 
managing ‘set’ processes. They must meet the challenges of each phase of the project life cycle, and 
even oversee the dissolution of efforts when the project is completed. 

Project managers must work with a diverse group of characters to complete projects. They are 
typically the direct link to the customer and must manage the tension between customer expectations, 
and what is feasible, reasonable and agreed within the project. Project managers provide direction, 
coordination and integration to the project team, which is often made up of parttime participants who 
are loyal to their functional departments. They must often work with a cadre of ‘outsiders’ —vendors, 
suppliers, subcontractors—who may not necessarily share the same project allegiance. 

Project managers are ultimately responsible for performance (frequently with too little authority). 
They must ensure that appropriate tradeoffs are made between the time, cost and performance 
requirements of the project. At the same time, unlike their functional counterparts, project managers 
generally possess only rudimentary technical knowledge to make such decisions. Instead, they must 
orchestrate the completion of the project by having the right people, at the right time, to address the 
right issues, make the right decisions and carry out. the project’s activities. 

While project management is not for the timid, working on projects can be an extremely rewarding 
experience. Life on projects is rarely repetitive; each day is different from the last. Since most projects 
are directed at solving some tangible problem or pursuing some useful opportunity, project managers 
usually find their work personally meaningful and satisfying. They enjoy the act of creating something 
new and innovative. Project managers and project team members can feel immense pride in their 
accomplishment, whether it is a new bridge, a new product, or needed service. Project managers are 
often ‘stars’ in their organisation and can be remunerated well. 

Good project managers are always in demand. Every industry is looking for effective people who 
can get (the right) things done, on time, on cost and to the customer's satisfaction. Undoubtedly, 
project management is both a challenging and exciting profession! 

Chapter 14 reviews the skills that a typical, competent, project manager will possess. From 
leadership skills to change management abilities—an adept project manager is truly a multi-talented 
individual. 


1.4 THE IMPORTANCE OF PROJECT MANAGEMENT 


Project management is no longer a ‘sidelined’ management technique. It is rapidly becoming a 
standard way of doing business. An increasing percentage of a typical organisation's effort is being 
devoted to projects. The future promises an increase in both the importance and the role of projects in 
contributing to the strategic direction of organisations. Several reasons are briefly discussed below. 


1.4.1 Compression of the product life cycle 

One of the most significant driving forces behind the demand for project management is the shortening 
of the product life cycle. For example, today in hightech industries, the product life cycle is averaging 
one to three years. Only 30 years ago, life cycles of 10 to 15 years were not uncommon. Time to 


PART 1 SETTING THE SCENE 


market for new products with short life cycles has become increasingly 
Figure 1.4 Product life cycles important. A common rule of thumb in the world of hightech product 
development is that a six-month project delay can result in a 33 per 





cent loss in product revenue share, or competitors gaining a market 
advantage. Speed, therefore, becomes a competitive advantage and 
an increasing number of organisations are relying on cross-functional 
project teams to get new products and services to the market as quickly 
as possible. Figure 1.4 illustrates the need to have a ‘pipeline’ of products 


Net Revenue 


in various states of development, growth, maturity and decline, in order 
to ensure revenue streams for the organisation keep rolling in. 
The shortening of the product life cycle has meant that alternative 





Time approaches to the management of projects have had to be considered. 

Scrum, and its Agile variants, are often the preferred approaches for 
Source: @ 2018 Dr Neil Pearson wore: : ea š 
bringing product/s to market quicker and for better aligning customers 


everchanging requirements. 


1.4.2 Complexity 

The growth of new knowledge has increased the complexity of projects because projects typically 
encompass the latest advances. For example, building a road 30 years ago was a relatively simple 
process. Today, each area has increased in complexity, including materials, specifications, codes, 
legislation, aesthetics, equipment and required specialists. Similarly, in today’s digital/internet age, it 
is becoming hard to find products that do not leverage the internet in some aspect of their function. 
Product complexity has increased the need to integrate divergent technologies. Project management 
has emerged as an important discipline for achieving the task of managing such complexity. 


1.4.3 Triple bottom line (planet, people, profit) 


The threat. of global warming has brought sustainable business practices to the forefront. Businesses 
can no longer simply focus on maximising profit to the detriment of the environment (and indirectly 
therefore, society). Efforts to reduce carbon footprint and utilise renewable resources are realised 
through effective project management. The impact of this movement towards sustainability can 
be seen in changes in the objectives and techniques used to complete projects. See Snapshot from 
Practice: Gold Coast sustainable teaching hospital. 


1.4.4 Corporate downsizing 


The last decade has seen a dramatic restructuring of organisational life. Downsizing (or ‘rightsizing’ 
if still employed) and sticking to core competencies have become necessary for the survival of many 
firms. 

The structure of middle management is a mere skeleton of the past. In todays ‘flatter’ and ‘leaner’ 
organisations, where change is a constant, project management is replacing middle management 
as a way of ensuring that things get done. Corporate downsizing has also led to a change in the 
way organisations approach projects. Companies outsource significant segments of project work, 
and project managers have to manage not only their own people, but also resources in different 
organisations. 


1.4.5 Increased customer focus 


Increased competition has placed a premium on customer satisfaction. Customers no longer simply 
settle for generic products and services. They want customised products and services that cater to 
their specific needs. This mandate requires a much closer working relationship between the provider 
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and the receiver. Account executives and sales representatives are assuming more of a project 
manager's role as they work with their organisation to satisfy the unique needs and requests of clients. 

Increased customer attention has also prompted the development of customised products and 
services. For example, 10 years ago, buying a set of golf clubs was a relatively simple process—yjou 
simply picked out a set based on ‘price and feel’. Today, there are golf clubs for tall players, short 
players, clubs for players who tend to ‘slice’ the ball, clubs for those who ‘hook’ the ball, high-tech clubs 
with the latest metallurgic discoveries ‘guaranteed’ to improve stroke distance, and so forth. Project 
management is critical to development of customised products and services, and to understanding 
and sustaining relationships with customers. 


1.4.6 Organisational change management 


Managing projects (large or small) can bring new challenges to an organisation. Change is an accepted 
‘norm’ in organisations today. However, too much change in one specific area of an organisation can 
have negative effects. An example of this might be the impact on day-to-day operations, the loss 
of key personnel and not being able to balance the introduction of new projects with operational 
activities. Managing a group of projects as a portfolio or program enables the organisation to take a 
holistic view of change across and within areas of the organisation, facilitating an easier, thorough 
preparation of staff and activities for the required changes to occur. 

Table 1.7 indicates some of the vendor-specific and more general organisational change 
management approaches that are popular in the current marketplace. 


Table 4.7 Organisation change management approaches 





Source (author/organisation) | Approach More information 
PMI Managing Change in Organisations: A https://www.pmi.org/pmbok- 
Practice Guide Quide-standards/practice-guides/ 
change 
Prosci ADKAR: Awareness, Desire, Knowledge, _ https://www.prosci.com/adkar 
Ability, Reinforcement? 
Change Management Institute The Effective Change Manager: The https://www.change-management- 
Management Body of Knowledge institute.com/buycmbok 
Kotter 8-Step Process for Leading Change https://www.kotterinc. 
com/8-steps-process-for-leading-change/ 
Anderson The Change Leader’s Roadmap https://www.beingfirst.com/services/ 
Methodology change-leaders-roadmap-methodology/ 


1.4.7 Small projects represent big problems 


The velocity of change required to remain competitive, or to simply keep up, has created an 
organisational climate in which hundreds of projects may be implemented concurrently. This climate 
has created a multiproject environment with a plethora of new problems. Sharing and prioritising 
resources across a portfolio or program of projects is a major challenge for senior management. 
Many firms have no idea of the problems involved, with inefficient management of multiple small 
projects. Small projects typically carry the same or more risk as do large projects. Small projects 
are perceived as having little impact on the bottom line because they do not demand large amounts 
of scarce resources and/or money. Because so many small projects are going on concurrently and 
because the perception of the inefficiency impact is small, measuring inefficiency is usually non 
existent. Unfortunately, many small projects soon add up to large sums of money. Many customers 
and millions of dollars are lost each year on small projects in product and service organisations. 
The failure of small projects can represent hidden costs to an organisation, yet often these costs are 
not measured. 
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SNAPSHOT FROM PRACTICE Gold Coast sustainable teaching hospital 





Construction of a new teaching hospital was completed 
in 2012 at a cost of A$1.76 billion. It is one of Australia’s 
largest ever public health infrastructure projects. 

The hospital site includes state-ofthe-art healthcare 
facilities, 750 hospital beds (170 O00 square metres of 


floor space), on-site research facilities, relaxation areas 
for patients’ family and friends, retail areas, car parking for 
over 2000 cars, easy access to the public light rail system 
and a private hospital co-located on the same site. 
Providing a mix of teaching, research an@ health 


care, the hospital has become an example of how to 
build with the public in mind. The project had numerous 
environmental considerations to meet, and a profit 
model formed on the grounds of activity-based funding, 
as opposed to a traditional ‘block’ funding of services. 
Examples of the environmental and sustainability elements 
that were included in the construction are water harvesting, 
energy-efficient lighting, recycling and waste reduction, an 
energy-efficient façade, the use of recycled materials and 
a reduction in the use of PVCs (and polyurethane-based 
glues). 

This ‘fit of planet, people ane profit provides a 
benchmark for future teaching hospital construction and 
no doubt will be replicated in other Australian states. 








Shuttersteck/zsteck 


Source: Adapted from Lend Lease n.d., ‘Stage 1 Entry Gold 
Coast University Hospital, Australian Construction Achievement 
Aware’, http//acaa.netau/wp-content/uploads/201 4/05/ 
Gol@.Coast-University-Hospital-@ueensland_lo.pdf. 


The building of this new teaching hospital on the Gold Coast represents 
a large preject that might lead to other, similar projects. 


Organisations with many ongoing, concurrent small projects face the most difficult. project 
management problems. A key question becomes how to create an organisational environment that 
supports multiproject management. A process is needed to prioritise and develop a portfolio or 
program of small projects that supports the mission of the organisation. 

In summary, there are a variety of forces interacting in today's business world that contribute 
to the increased demand for good project management across all industries and sectors. Project 
management is ideally suited for a business environment that requires accountability, flexibility, 
innovation, speed, and continuous improvement. 


1.5 PROJECT MANAGEMENT TODAY: A HOLISTIC 
APPROACH 


Competing in a global market that is influenced by rapid change, innovation and time-to-market 
challenges, means organisations are increasingly becoming involved in managing projects. Being 
able to coordinate and manage projects in such a changing environment is therefore essential. To 
meet this challenge, organisations are increasingly centralising their project management processes 
and practices. For example, Bell”, IBM® and the ANZ™ Bank often all have over 1000 projects being 
implemented concurrently across differing cultures. But how do these organisations oversee the 
management of so many projects? How were these projects selected? How do they ensure performance 
measurement and accountability? How can project management continually be improved? 
Centralisation entails the integration of all project processes and practices to improve project 
management. Integration is designed to improve project management in the whole organisation over 
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the long haul. The rationale for the integration of project management to the wider organisation is to 
provide senior management with: 


E an overview of all project management activities 

E a ‘big picture’ of how organisational resources are being used 

E an assessment of the risk their portfolio of projects represents 

a metric for measuring the improvement of managing projects, relative to others in the industry 
linkages to senior management with sponsorship and accountability 


performance management of projects, and linkages to executive pay and remuneration 


a clear definition of benefits from projects, and tracking and delivery of these benefits across the 
life of a portfolio or program (and beyond) into the organisation. 


Full insight of all components of the organisation is crucial for aligning internal business resources 
with the requirements of the changing environment. Integration enables management to have greater 
flexibility and better control of all project management activities. 

But then, operationally, what does project management. integration mean? It necessitates 
combining all of the major dimensions of project management under one umbrella. Each dimension 
is connected in one seamless, integrated domain (Figure 1.6). Integration means applying a set of 
knowledge, skills, tools and techniques to a collection of projects in order to move the organisation 
towards its strategic goals. This integration movement represents a major thrust of project-driven 
organisations, across all industries. 


1.5.1 Alignment of projects with organisational strategy 


Today, projects are the modus operandi for delivering strategy. Yet in some organisations, the 
selection and management of projects often fails to support the strategic plan of the organisation. 
Strategic plans are written by one group of managers, projects may be selected by a different group, 
and projects may be implemented by yet another. Independent decisions made by different groups 
of managers create a set of conditions that can 
lead to conflict, confusion and (frequently) a 
dissatisfied customer. Under such conditions, the 


Figure 1.6 Int 





resources of the organisation are wasted in non 


External environment 


valueadded activities/projects. 

Since projects are often the preferred modus 
operandi, the strategic alignment of projects is of 
major importance to conserving and effectively 
using an organisation's resources. Selection 
criteria are needed to ensure each project is 
prioritised and contributes to strategic goals. 
Anything less is a waste of scarce organisational 
resources—people, capital and equipment. 
Ensuring alignment requires a selection process 
that is systematic, open, consistent and balanced. 
All of the projects selected become part of a 
project portfolio that balances the total risk for 
the organisation. Management of the project 
portfolio ensures that only the most valuable 
projects are approved and managed across the 








Organisational culture 








Strategic 
alignment 








Portfolio 
management 


Program management 


entire organisation. 
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1.5.2 Management of projects through portfolio management 


The portfolio management provides the capability to ‘zoom out’ to a wide-angle view or, ‘zoom in’ to 
a very specific element of a specific project activity or process. Full insight of all components of the 
organisation is crucial for aligning internal business resources with the requirements of the changing 
environment. Project portfolios are frequently managed by a portfolio or program office that serves 
as a bridge between senior management and project managers and their teams. The major functions 
of portfolio management are to: 


oversee project selection and prioritisation 

monitor aggregate resource levels and skills 

encourage use of best practices 

balance projects in the portfolio in order to represent a risk level that is appropriate to the organisation 


improve communication among all stakeholders 


monitor the delivery of benefits across the portfolio into the organisation 
educate and train project managers 
instigate communities of practices where project managers can share lessons-learned 


E 

= 

E 

E 

E 

m create a total organisational perspective that goes beyond ‘silo’ thinking 

E 

a 

E 

@ undertake continuous improvement of ‘best practice’ methodology, processes and templates 
E 


report on progress and provide updates on cost, time and scope dimensions to executive 
management 


manage cross-dependencies between programs and projects 


establish governance and approval ‘gates’ so the business needs are continually validated to 
ensure project activity delivers the requirements for an ever-changing business 


™ manage risk across the portfolio, program and projects. 


Portfolio management manages the integration of elements of organisational strategy, with 
projects (along with their interdependencies). At the project level, the management of the portfolio is 
directed towards creation and use of best practices. 


1.5.3 The technical and socio-cultural dimensions 
of implementing projects 


Senior management is often involved in selecting projects but is seldom involved in implementing 
them. Implementing the project is the challenge! 

There are two dimensions within the actual execution of projects (Figure 1.7). The first dimension 
is the technical side of the management process, which consists of the formal, disciplined, purely 
logical parts of the process. This technical dimension includes scoping, planning, scheduling 
and controlling projects. Clear project scope statements (captured in the scope document) are 
written to link the business needs of the project and the customer and to facilitate planning and 
control. Creation of the deliverables and work breakdown structure (WBS) facilitates planning and 
monitoring the progress of the project. The WBS serves as a common reference point that links 
all levels in the organisation, major deliverables and all work, right down to the tasks in a work 
package. Effects of project changes are documented and traceable. Thus, any change in one part 
of the project is traceable to the source by the integrated linkages of the system. This integrated 
information approach can provide all project managers and the customer with decision information 
that is appropriate to their level and needs. A successful project manager will be well-trained in the 
technical side of managing projects. 
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A second (and opposing) dimension is the socio-cultural 
side of project management. In contrast to the orderly world of E N E EIEEE 
project planning, this dimension involves the much messier and process 
often contradictory and paradoxical world of implementation. 
It centres on creating a temporary social system within a 
larger organisational environment. that. combines the talents 


Figure 4.7 The technical and socio-cultural 
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of a divergent set of professionals working to complete the 


project. Project managers must shape a project culture that 





Leadership 


Problem solving 
stimulates teamwork and high levels of personal motivation, as Teamwork 
well as a capacity to quickly identify and resolve problems that Reoouenon 





threaten project work. This dimension also involves managing 
the interface between the project and external environment. 
Project managers have to assuage and shape expectations 


Customer expectations 


of customers, sustain the political support of executive 
management, negotiate with their functional counterparts, 
monitor subcontractors and so on. Overall, the project manager 
must build a cooperative social network among a divergent set 
of allies with varying agendas, commitments and perspectives. 

Some suggest that the technical dimension represents 
the ‘science’ of project management while the socio-cultural 
dimension represents the ‘art’ of managing a project. To 
be successful, a project manager must be a master of both. 
Unfortunately, some project managers become preoccupied 
with the planning and technical dimension of project management and neglect the socio-cultural 
aspects. Often their first real exposure to project management is through project management 
software, and they become infatuated with network diagrams, Gantt charts and performance 
variances: in essence, they attempt to manage a project from a distance. Conversely, there are other 
managers who manage projects by the ‘seat of their pants’. They rely heavily on team dynamics and 
organisational politics to complete a project. Good project managers balance their attention between 
both the technical and socio-cultural aspects of project management. 


ummary 


Powerful environmental forces are contributing to the rapid expansion of project management approaches to 
business problems and opportunities. A project is defined as a non-routine, one-time effort that is limited by time 
and resources and by performance specifications designed to meet customer needs. One of the distinguishing 
characteristics of project management is that it has both a beginning and an end, and typically consists of four 
phases: Initiating, Planning, Executing and Closing, supported by Monitoring and Controlling. 

Effective project management begins with selecting and prioritising projects that support the firm’s mission 
and strategy. Successful implementation requires both technical and socio-cultural skills. Project managers have 
to plan and budget projects as well as orchestrate the contributions of others. 

In summarising this chapter, it is helpful to reflect on and learn from some of the typical reasons projects fail, and 
conversely to learn why others are successful. A list of some of the typical reasons projects might fail is provided 
so you can strive towards avoiding these potential pitfalls: 


The projectis not aligned to organisational strategy. 

There is a lack of top management/sponsor support. 

Political discord/disagreement exists within the organisation. 
There is poor/inadequate estimating of time, resources and costs. 
The project works backwards from a given ‘drop-dead’ date. 

The project management personnel are inexperienced. 
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There is a fragmented team and team values. 

[here are poorly/vaguely defined requirements (scope). 

There is a lack of user (customer) involvement. 

The testing and piloting stages are skipped. 

nrealistic requirements/expectations are set from the outset. 

[here is scope-creep (and the lack of a formal change/variation management process). 
There is poor/lack of communication. 

Project warning signs (e.g. cost and time variances) are ignored. 


EEEE EEEN E 
= 





[here are poor governance and control mechanisms. 


If lessons-learned are implemented into daily practice by the project manager, such potential pitfalls should be 
avoidable in future. 


Listed below are some of the reasons often cited for project success: 


m The project has a defined project steering committee, an agreed committee charter and appropriate levels of 
accountability. 
m There is asound business case that informs and guides the ongoing business need for the project. 





m There is a wel-articulated story of the strategic alignment of the project, supported by an active, positive sponsor who is 
respected across all levels of the business. 

Project manager and project team skills are matched to the complexity and challenges of the project. 

m An approved methodology is used that is actively applied to the project and is communicated to the project team 
and stakeholders beyond the immediate project. 

There is tightly defined and communicated governance, including team roles and responsibilities, and there is 
transparency of the governance across the project environment. 


m A gateway review process actively assists the project in a positive manner, as opposed to a blame culture. 


There is a planned and prepared communication strategy and change management strategy and these are 
appropriate to the type of project. 


www.aipm.com.au https://www.axelos.com 

Www.asqa.gov.au http://www.ipma.world 

www.health.qld.gov.au/gcuhospital https://www.praxisframework.org 

www.pmi.org https://apmg-international.com 

Australian Institute of Project methodology project 
Management (AIPM) monitoring and controlling project life cycle 

Australian Skills Quality Authority organisational change management Project Management Institute (PMI) 
(ASQA) portfolio project manager 

framework program vocational education and training (VET) 


Review questions 


4. Define a project: What are the main characteristics that help differentiate projects from other functions carried out in 
the daily operations of the organisation? 


2. Whatare some of the key environmental forces that have changed the way projects are managed? What has been the effect 
of these forces on the management of projects? 


3. Why is the implementation of projects important to strategic planning and the project manager? 
4. ‘The technical and socio-cultural dimensions of project management are two sides of the same coin.’ Explain. 
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5. What is meant by an integrative (holistic) approach to project management? Why is this approach important in today’s 
environment? 


6. What are some of the key reasons for project failure? 


7. What are the main phases in the PMI’s Project Management Body of Knowledge (PMBOK) life cycle? What is the 
purpose of each of these phases? 


8. What are the PMI and PRINCE2? 
9. What are the differences between a framework, a methodology and a standard? 


10. What are the stages ofa product life cycle? 





4. Use the internet to identify all the infrastructure projects currently taking place in your local area. How many are you 
able to find? What is the value of the projects? How long are they planned to take? 

2. Individually identify what you consider to be the greatest achievements accomplished by humankind in the last decade. 
Now share your list with other students in the class and come up with an expanded list. Review these accomplishments 
in terms of the definition of a project. What does your review suggest about the importance of project management? 

3. Individually identify a recent project. Are both socio-cultural and technical elements factors in the success or difficulties 
in the projects? 

4. Review the PMI site (www.pmi.org). 

{a) Review general information about the PMI, as well as membership information. 

{b) See if there is a PMI chapter in your state. If not, where is the closest one? 

{c) Use the search function at the PMI home page to find information on PMBOK. What are the major knowledge areas 
of PMBOK? 

{d) Explore other links that PMI provides. What do these links tell you about the nature and future of project 
management? 

5. Now review the AIPM site (www.aipm.com.au). 


{a) Review general information about the AIPM, as well as its membership information. 
{b) Review the benefits of being a member of the AIPM. 





Case 


Have a look at Macworld’s Apple predictions 
(nttps://www.macworld.co.uk/news/apple/apple-predictions-20 18-35 10027/). 


41. Choose one of the product streams and draft a hypothetical product life cycle diagram depicting which stage you 
think the product is currently at (ie. Development, Growth, Maturity or Decline). Also, indicate product releases you 
would like to see, using your own innovative ideas. 
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Learning elements 


Understand various project management frameworks and recognise which of 
these typically suit what environments. 


Understand project life cycle types and when to select one over another. 
Achieve a high-level understanding of PRINCE2. 

Achieve a high-level understanding of ISO 21500:2012. 

Achieve a high-level understanding of Scrum. 

Achieve a high-level understanding of Lean Six Sigma. 

Achieve a high-level understanding of the APM framework. 

Achieve a high-level understanding of the Praxis® framework. 


Further develop knowledge of the Project Management Body of Knowledge (PMBOK), 
the life cycle and the similarities and differences between PMBOK and PRINCE2. 


In this chapter 


2.1 Introduction 

2.2 Life cycle types and their selection 

2.3 An introduction to PRINCE2 

2.4 An overview of ISO 21500:2012 Guidance on Project Management 
2.5 An introduction to the Scrum approach 

2.6 An introduction to the APM framework 

2.7 An introduction to Lean Six Sigma and the DMAIC process 

2.8 An introduction to the Praxis framework 

2.9 An introduction to PMBOK 


Summary : 
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2.1 INTRODUCTION 


Advances in project management as a discipline have improved substantially over the last 40 years and 
today’s project manager has a plethora of relatively mature frameworks and methodologies to select 
from. All are well documented, supported by training programs, backed by professional communities, 
and generally have a ready pool of skilled project managers available. Although the focus of this text 
is the Project Management Institute’s (PMI) ‘life cycle’ approach (as this most closely aligns with the 
Diploma and Certificate IV in Project Management Practice), the reader needs to be aware that other 
widely used major frameworks and methodologies also exist in the global marketplace, which are 
predominantly used within specific industry sectors (such as Agile in software engineering projects, 
and Predictive (PMI) in the construction industry). 

Although we often refer to generic project management approaches, the developers of the 
approaches discussed in this chapter have determined whether their approach is a methodology 
(i.e. a set of prescriptive principles, tools and practices) or a framework (i.e. a looser and more flexible 
structure that allows room for the inclusion of other practices, tools and techniques). 

A good project management resource on the subject is located at: https//www.projectmanagement. 
com/articles/278600/Why-YoureConfusingFrameworks-with-Methodologies. 

In relation to the approaches discussed in this chapter, the developers classify them as follows: 


PRINCE2®°—methodology 

ISO 21500:2012 Guidance on Project Management—framework (also a standard) 
Scrum (Scrum Guide™) —framework 

Association for Project Management Body of Knowledge (APM BoK)—framework 
Lean Six Sigma DMAIC—framework 


The Praxis Framework™ framework 


Project Management Institute’s A Guide to the Project Management Body of Knowledge, The 
PMBOK® Guide—good practice framework (also a standard ANSI/PMI 99-001-2017). 


The approaches that will be introduced in this chapter include the following. 


m PRINCE2 was initially developed by the UK Office of Government Commerce (now known 
as the Cabinet Office) and is used extensively by the UK Government (https://www.gov.uk/ 
government/publications/best-management-practice-portfolio/about-the-office-of-government 
commerce#links). PRINCE2 is beginning to be recognised and applied internationally and is 
gradually being adopted by governments and large information and communication technology 
(ICT) providers globally. The PRINCE2 methodology offers nonproprietary best-practice 
guidance on project management. AXELOS (https://www.axelos.com) controls accreditation 
and standards for the PRINCE2 method, which it publishes through best practice guidance. Like 
the PMI’s PMBOK, PRINCE? is part of a large suite of methodologies incorporating portfolio, 
program, risk, value (benefits) and ITIL (service management). 


@ ISO 21500:2012 is described as guidance for project management. It provides a highJevel 
description of concepts and processes that are considered to form good practice in project 
management. This guidance also considers a wider context by including elements such as the 
organisation's strategy, governance, company operations and benefits. Elements of ISO 21500:2012 
appear to be modelled on elements of the Project Management Institute’s Project Management 
Body of Knowledge, and therefore at its core takes a similar life cycle approach (initiating, 
planning, implementing, closing and controlling). This is ina context of operating in a strategically 
aligned organisation, where each investment (project) has a valid business case and delivers 
benefits back to the business as a result of undertaking the project work. 


CHAPTER 2 POPULAR FRAMEWORKS AND METHODOLOGIES 


= Scrum: The term ‘Scrum’ was introduced by Takeuchi & Nonaka (1986). In this paper, they 
observed that projects that use small, cross-functional teams historically tend to produce the best 
results. ‘Scrum’ was one of the earliest implementations of ‘the new new product development 
game’ that emerged out of this work (https://hbr.org/1986/01/Athene w-newproductdevelopment- 
game). Jeff Sutherland set about formalising and realising this new way of working by applying 
it to software product development. Using the study by Takeuchi and Nonaka as a platform, Jeff 
Sutherland subsequently published Scrum: The Art of Doing Twice the Work in Half the Time 
(Sutherland 1993). Ken Schwaber (software developer, product manager and industry consultant) 
is also associated with the development of Scrum. He presented Scrum as a formal development 
process at an OOPSLA (Object-Oriented Programming, Systems, Languages and Applications) 
conference in 1995. In 2001, the ‘Agile Manifesto’ (a formal declaration of four key values and 12 
principles towards an Iterative and people-centric approach to software development) was born. 
This started the ever-expanding world of Agile and since then, many variants of Scrum have 
emerged including: 


— Kanban—based on the much earlier Toyota Production System, which came into existence post- 
World War II (commonly known as lean thinking). 


— XP or eXtreme Programming—created by Kent Beck as a part of the Chrysler Comprehensive 
Compensation System (C3) in approximately 1996. Focused on micro-increments (smaller 
groups of requirements) and a test-first approach where tests are determined up-front for each 
micro-increment. 


— Scrum of Scrums—a way of carving up large (development) teams into sub-teams and cascading 
the reporting and management of ‘stories’ both upwards and downwards among the teams via 
ambassadors. 


— LeSS or Large-Scale Scrum framework—a framework to guide in the scaling of multiple concurrent 
scrums. Also LeSS Huge, where area product owners (APOs) report to a product owner for large 
product developments where a single product owner cannot cope with the demands of multiple con- 
current sprints. 


— Dynamic System Development Model (DSDM) framework—a formalisation of the Rapid Applica- 
tion Development (RAD) methodology. DSDM was created in 1994 to address problems associated 
with a traditional approach to development. A founding member of the Agile Alliance, DSDM sup- 
ports the Agile Manifesto and Principles and has been expanded to provide governance around the 
context of Agile. 


— Scaled Agile Framework (SAFe)—often described as a knowledge base of proven, integrated pat- 
terns for Lean—Agile implementations and truly brings together aspects of both Lean and Agile. It 
incorporates aspects of DevOps and the Continuous Delivery Pipeline. 

This text will take the Scrum approach, since it forms part of the original thinking regarding 

this classification of project management. It additionally forms the basis for the major principles, 
approaches and techniques that are used in all the variants (as outlined above). 


E Lean Six Sigma and the DMAIC process: Lean Six Sigma combines the benefits of lean 
thinking (which originated out of the Toyota Production System in Japan in the 1940s) and 

the statistical techniques of Six Sigma (originating from Motorola in the United States in the 

1980s), into a single approach for the management of continuous improvement projects. In 

recent times, this approach to the management of continuous improvement projects has become 

popular, with the DMAIC approach being applied to the routine management of continuous 

improvement project work. 

DMAIC (Define, Measure, Analyse, Improve, Control) is applied to the improvement of existing 
processes. For the development of new processes, the DMADV approach (Define, Measure, Analyse, 
Design, Verify) is used. The Lean Six Sigma approach has become extremely popular in recent years as 
the approach for continuous improvement projects of all sizes and complexities. It is also interesting 
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to note that some of the values, principles and techniques adopted in Scrum are to be found in Lean 

Six Sigma (no doubt furthering the popularity of the approach, as organisations look to become more 

agile in their da yto-day operations). 

@ Praxis is an opensource project management framework. It is a free community-driven portfolio, 
program, and project management (P3M) approach towards the management of projects, 
programs, and portfolios. Praxis Framework describes how: 


The challenge now facing the profession is to find consistency and consensus across the many 
guides so that they may be used together in an integrated framework. 

Praxis is designed to provide that integration. It takes the principles of existing, proven 
guides and adapts them so that they have a common terminology, structure and approach. 
It also supports these with a library of information drawn from published experts and the 
practical experience of the P3M community (PFL 2015 ). 


The framework consists of five interconnected elements: 

The knowledge section reflects the content of the guides that are often called bodies of 
knowledge. Its component functions are the building blocks of the [portfolio, program 
and project] management discipline. These functions are integrated in processes that 
correspond to the phases of the life cycle. 

The processes are combined with documentation standards to form the Praxis method. 

Competence defines the required abilities of individuals who apply the functions 
and methods. 

Capability maturity describes the stages of organisational development that ultimately 
lead to a culture of effective and efficient application of functions and methods. 


... The Praxis library is an accumulation of information from a wide variety of sources 
that complements the other four sections with additional detail and thought-provoking debate 
(PFL 2015). 


Although not currently a mainstream approach to the management of projects, it has recently 
gained support from APMG International, who now offer a mainstream certification option. 
Additionally, the Praxis framework has recognised Agile and includes guidance on how to integrate 
Agile with the Praxis framework. 


= APM life cycle and approach: The Association for Project Management (APM) is the UK’s arm 
of the International Project Management Association (IMPA). It is: 


... a federation of about 70 Member Associations (MAs) [which] develop project management 
competencies in their geographic areas of influence, interacting with thousands of 
practitioners and developing relationships with corporations, government agencies, 
universities and colleges, as well as training organizations and consulting companies 
(IPMA 2018 ). 


Founded in 1965, the IPMA exists as arguably the world’s first project management. association. 
Its national associations collaborate to advance the profession's achievements in project and 
business success; evidence of their strategic vision is offered in the way the association changed 
its name from INTERNET to IPMA in the early 1970s. 


The APM is associated with IPMA, but it also offers a (popular) project management framework 
in its own right, as documented in the AP's Body of Knowledge (6th edn). It is essentially a 
Predictive life cycle approach that is inclusive of the wider environment in which projects operate. 
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m PMBOK: The PMI’s A Guide te the Preject Management Bedy ef Knewledge (PMBOK® Guide) 
(PMI 2017a), upon which this text is based, provides a generic life cycle approach that can be 
applied to projects of all sizes and complexities and in all industries (including the public sector). 
PMBOK also provides a valuable body of knowledge around project management in general as 
it provides an understanding of some of the key tools and techniques that are used and applied 
within other frameworks and methodologies (such as PRINCE2, Praxis and ISO 21500:2012). PMI 
has become a globally accepted body of knowledge and is practiced around the world. There 
are many PMI chapters dotted across the globe who support, promote and further develop the 
profession of project management: it is beyond doubt the largest and most widespread of all the 
approaches that are described in this text, and forms the basis of knowledge within the current 
Australian Certificate IV and Diploma in project management. 


Readers should note that this text has been updated since its first edition and includes contemporary 
thinking from the PMI to align with A Guide te the Preject Management Bedy ef Knewledge (6th edn), 
which was released towards the end of 2017. The PMI partnered with the Agile Alliance to create the 
Agile Practice Guide (PMI 2017b). 

As will be discussed in this chapter, there is no single framework or methodology that suits all 
organisations, working cultures and industries. In practice, an overarching methodology is usually 
chosen and internalised within the organisation, providing the basis for project management 
governance, best practice, templates and education programs. Selecting the best framework or 
methodology for your organisation is not only key for embedding best practice project management, 
but also for providing a common understanding and vocabulary with other project managers in your 
organisation and with suppliers and peers within your industry. 

This chapter will provide an overview of each of the popular approaches described (PRINCE2, ISO 
21500:2012, Scrum (Agile), Lean Six Sigma, APM, Praxis and PMBOK) in the management of projects 
within organisations. 


2.2 LIFE CYCLE TYPES AND THEIR SELECTION 


Before launching into an overview of each of the frameworks, this short section seeks to position 
the discussions and decisions a project manager will typically consider many times during their 
project management career, in terms of which project management approach should be applied for a 
particular project. 

First, the project manager has to consider the type of work being undertaken, as this will 
fundamentally influence the approach taken in the management of a project. We could, for example, 
leverage a decision-making taxonomy known as the ‘Cynefin framework’ to assist us (refer to http:// 
cognitive-edge.com/videos/cynefinframework-introduction/). 


E For projects where there is a low degree of technical uncertainty and low degree of requirements 
uncertainty, we would be tempted to use more linear Predictive approaches to the management 
of projects (i.e. ‘simple’ approaches). 


m For projects where there is a medium degree of technical uncertainty and medium degree 
of requirements uncertainty, we would be tempted to use more adaptive approaches (i.e. 
‘complicated’ or even ‘complex’ approaches). 


E Where there is a high degree of technical uncertainty and high degree of requirements 
uncertainty, these are inherently risky, and the ability to solve these even with more adaptive 
approaches should be questioned. 


This can potentially facilitate choosing the type of project management framework that may 
feasibly be applied. In Figure 2.1, ‘requirements uncertainty’ is charted against ‘technical degree of 
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Figure 2.1 Uncertainty informs ay 
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uncertainty’, with the zones of ‘simple’, ‘complicated’, ‘complex’ and ‘chaos’ indicated for the type of 
work being considered in the project. These zones help to indicate the choice of project management 
life cycle approach. 

Nete: A preject life cycle describes the stages a project goes through from beginning to end— 
regardless of the project management. approach. Some generic project life cycles include Predictive, 
Iterative and Adaptive. General definitions of these follow. 

Predictive life cycle (waterfall or fully plan driven): A Predictive life cycle arrangement relies on 
the up-front initiation, planning and capturing of requirements prior to any development or execution 
activity. Change is tolerated (but carefully managed) via a change request process. 

Incremental life cycle: In approaching a project incrementally, we would have a confirmed 
idea about what we are to deliver (e.g. a five-storey block of apartments). However, the project is 
delivered in increments against the confirmed idea. We would build the foundations based on the 
original floor plan of the building, then erect the building’s structure, then fit out, then landscape. 
The project has effectively delivered the initial idea, but via a number of increments. Each 
increment could go through each stage of initiating, planning, executing and closing before the 
next stage is started (i.e. sequentially). More often, stages are run in parallel, for example, the fit- 
out would be started on the completed first floor as the construction of the second floor continues. 
In Incremental approaches, the ‘whole’ product, service or results is not handed over until the end 
of the project. 

Iterative life cycle: Here, the project has an overall vision, but the detail is not defined until 
an iteration takes place, at which point detail about the ‘what’ and the ‘how’ is worked out for an 
iteration. For example, in Iteration 1, in designing a building, the architect and customer agree the 
outcome is a sketch of the building and duly complete this sketch. In Iteration 2, the architect and 
customer agree initial blueprints of the building will be produced and the architect produces a set of 
blueprints. In Iteration 3, the customer and architect decide the outcome will be a modified but agreed 
blueprint upon which construction plans can be based. They tweak a few design elements and confirm 
the plans. The process continues all the way through to a constructed building. As can be seen, each 
iteration has a defined outcome and adds more functionality to each iteration until the end results 
achieve the overall vision. 

Adaptive life cycle: This approach takes elements of both the Incremental and Iterative 
approaches and is often referred to as the ‘Agile’ approach. In Agile, a timebox (e.g. weeks needed 
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Figure 2.2 The life cycle continuum 
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for Sprints 1 to 4) agrees a set amount of work to be completed, which, at the end of the timebox, 
is potentially shippable and can be handed over to the business (or implemented). Each timebox 
incrementally adds functionality to the item under development, increasing its functionality. 

Figure 2.2 indicates which life cycle approach is more commonly applied, with ‘frequency of 
delivery’ appearing on the vertical axis and ‘degree of change’ on the horizontal axis. 

Survey tools to support approach selection 

Choosing which approach to use (or even hybrids of different approaches to use) can be asomewhat 
difficult task. It may be that the choice of approach is driven more by internal standards than by what 
is the most fitting choice. To assist the project manager in making informed recommendations, there 
are several assessment tools available. For example, the PMI’s Agile Practice Guide (Appendix X3) 
has ‘Agile Suitability Filter Tools’. Describing the presence and use of these tools is also common in 
other Agile approaches such as DSDM. The PMI’s approach differs as it considers not just Agile and 
Predictive approaches, but. also hybrid approaches in its recommendations when handling responses 
to a survey (PMI 2017b, pp. 125-138). 

The following sections of this chapter take amore detailed look at a number of project management. 
approaches introduced above. 


2.3 AN INTRODUCTION TO PRINCE2 


PRINCE2 (PRojects IN Controlled Environments) features a full life cycle outside what was seen as 
traditional project management, and includes richer start-up and governance structures than some 
other methodologies. Continual alignment checks are an integral part of the PRINCE2 methodology 
and require the project manager to ask the questions, ‘Are the outputs and outcomes—te be delivered 
by the project—still required by the business?’ and ‘What benefits are to be delivered, and how are 
these managed (owned) beyond project delivery?’ 

PRINCE2 has four components to its structure: principles, themes, processes and tailoring; these 
are explained below. 


2.3.1 Principles 


There are seven principles in PRINCE2 and all must be applied in order for the project to be PRINCE2. 
The principles represent guiding obligations and good practice. They also help to determine whether 
the project is genuinely being project managed as a PRINCE2 project. The principles are summarised 
in Table 2.1. 
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Table 2.1 Seven principles in PRINCE2 


Principles 


Continued business 
justification 


Learn from experience 
Defined roles and 
responsibilities 


Manage by stages 


Manage by exception 


Focus on products 





There is a valid business justification (Business Case) to start the project and the project remains required 
throughout its duration. 


Learning from previous lessons at the start-up of a project and during each stage of the project, as well as 
recording lessons at the end of the project. 


PRINCE2 has defined roles and responsibilities to ensure responsibilities of key roles within the project and the 
business are clearly understood. 


Defined stages are built into the process in PRINCE2 and, besides the start-up and closing stages, there are 
repeatable stages within the project delivery. 


Projects in PRINCE2 define tolerances for scope, time, cost, quality and additional risk and benefits. These are 
tightly controlled in a PRINCE2 project, and if tolerances are exceeded, then escalations must take place to the 
appropriate person in the defined role. 


Products are a key focus of PRINCE2 projects. There are two key categories of products: project management 
products, and products relating to the outcomes and outputs of the project itself. 


Tailor tothe environment PRINCE2 is a comprehensive process and is suitable for both simple and complex projects. It can be tailored to 


suit the environment. However, tailoring does not mean omitting any parts of the methodology, but instead (for 
example) adjusting the methodology to the structure and governance of the organisation. 


2.3.2 Themes 


PRINCE2 encompasses seven themes. These themes describe aspects of project management. that 
must continually be attended to, throughout the life of the project. The themes are summarised in 
Table 2.2. 


Table 2.2 Seven themes in PRINCE2 


Themes | Description 


Business Case 


Organisation 


Quality 


Plans 


Risk 


Change 


Progress 


The Business Case is critical in PRINCEZ2. It is created at the start of the project and progresses with the project, to 
ensure its continued justification. At key decision points, the Business Case is verified to ensure continued business 
justification. 


The organisation theme addresses the roles and responsibilities of a PRINCE2 project from the business, user and 
supplier perspectives, in addition to the PRINCE2 defined roles. 


Quality in relation to the products produced from the project, is key in PRINCE2. Quality is defined within products 
and appraised to ensure products are produced within defined tolerances. 


Plans define where and to whom products are delivered. PRINCE2 has three main types of plans: Project Plan, Stage 
Plan(s) and Team Plan(s) (optional). 


Risk is present in all projects. PRINCE2 integrates risk management into all aspects of the project management 
methodology. Both negative risk (threats) and positive risks (opportunities) are considered in a proactive approach to 
the identification, evaluation, and management of risk. 


Change (or variation) management is attended to within PRINCE2 by putting in place processes, roles and actions 
that can be invoked as a response to issues raised around quality, or other issues within the project. 


This theme validates the ongoing viability of plans, Performance-monitoring Plans, and the escalation process in the 
event of the project not proceeding to plan. 


2.3.3 Processes 


There are seven processes and these provide detail around the steps to be taken throughout the life of 
a PRINCE2 project. The processes are summarised in Table 2.3. 


Table 2.3 Seven processes in PRINCE2 


Processes Description 


Starting up (SU) a 
project 


The SU process focuses on the question: ‘Do we have a viable and worthwhile project?’ The project executive and 
the project manager are appointed within the SU process: the outline Business Case is prepared, previous lessons 
are captured, the project briefis prepared, and the initiation stage is planned. 
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Initiating a project (IP) The IP process defines the foundational information and prepares the key plans for the risk management strategy, 
the quality management strategy, the configuration management strategy and the communications management 
strategy. The Business Case is further refined and the Project Plan is assembled. Additionally, project controls are 
established (according to PRINCE2 guidelines). 

Directing a project (DP) DP is a critical project-control process. Overseen by the project board, DP establishes the controls between the 
project manager and the project board. The project board is accountable for making key decisions (continued 
business justification), while day-to-day management of the project is delegated to the project manager. 

Managing stage In SB, the interfaces between the project board and the project manager come into play. The project board must 

boundaries (SB) ensure that the current stage of the project has been successful and that the Stage Plan for the next stage is 
approved while ensuring the Project Plan and business justification remain valid, in light of the current risk profile. 

Controlling a stage (CS) The focus of CS isto control the delivery of the stage’s products, ensuring work remains within tolerance, and 
raising exception reports where tolerances are breached. Assigning ‘work to be done’ to the managing product 
delivery (MP) process, reporting on that work, and managing issues are all components of this process. 

Managing product The MP process is the domain of the team managers (the CS process agrees and sets the work to be done). It is in 

delivery (MP) MP, under the direction of a team manager, that the work actually occurs to agreed specifications and within defined 
tolerances. The MP process delivers one or more of the project’s products. 

Closing a project (CP) CP is the formal process entered into to close the project and can be planned or invoked for premature closure. 
CP is entered into when the objectives, as defined in the project initiation document (PID), have been achieved 
(including any approved changes). User acceptance is verified, the business is prepared to take on running and 
maintenance activities post-project closure, baseline and actual performance is reviewed, benefits are declared or 
handed over to the business and open risks and issues are handed to the business, with any follow-on plans. 


An overarching process map for PRINCE2 is depicted in Figure 2.3 and this diagram indicates the 
key interactions between the seven PRINCE2 processes. 


Figure 2.3 archine CE2 process map 








Corporate or program management or customer | 


T x A A 


v 





Project 
mandate 


Directing 


Managing Managing 

a stage a stage Closing a project 
boundary boundary (CP) 

(SB) (SB) 


Project 
startup 
(SU) 
































2 
? t l 
oirn 3 Controlling a stage Controlling a stage 
P (CS) (CS) 


Managing product delivery ik le 
we) (MP) 


Delivering 


© PART 1 SETTING THE SCENE 


2.3.4 Tailoring 


PRINCE2 is a comprehensive process in its own right; however, it can be tailored to suit an 
organisational environment, to manage large or small, simple or complex projects. Tailoring does not 
mean omitting any parts of the methodology. 


2.3.5 PRINCE2 around the world 


PRINCE2 has a particularly strong following in Europe. The Queensland State Govemment (in 
Australia) has adopted this methodology as its mandated methodology for ICT projects over certain 
cost/risk thresholds. Examples of other organisations and governments entities that have implemented 
PRINCE2 (as reported in trade press and media sites) include: 


TRANSPOWER: New Zealand’s high-voltage transmission company 
University of Western Australia 


Australian Department. of Parliamentary Services 


NRMA (Australian insurance company) 


SNAPSHOT FROM PRACTICE PRINCE2—The Departmen 


Parliamentary Services 





The Department of Parliamentary Services (DPS), 
based in Canberra, employs approximately 800 staff 
as an agency supporting Parliament House (a building 
containing about 4700 rooms, where about 3500 
people work). The DPS was split into three different 
departments each using its own project management 
system. However, with so many project management 
systems in place, many different approaches were being 
taken across the DPS to governance, responsibilities, 
quality and risk. In 2007, the DPS made the decision to 
implement PRINCE2 as the single project management 
methodology. 

The introduction of PRINCE2 caused a stark change 
in the delivery of projects and several benefits to the Sowce O20 tz Wawel earsee 
business were achieved including: 








m amore strategic perspective towards project 


Manage melmactorsine les m greater effectiveness in the engagement of 


m a consistent approach to project management training stakeholders 


and education m clearer governance and improved decision-making 


m common understanding of the methodology and arising out of having PRINCE2 defined roles. 

vocabulary used in project management The DPS is receiving direct business benefits in 
response to having adopted a PRINCE2 approach towards 
project management, with some of the (indirect) benefits 
going beyond project delivery. 


m benefits of being able to reuse project management 
resources (people) across the department 


m improved, more consistent, project reporting 


5 $ x f Source: Best Management Practice Case Study, www.apmg-international.com/ 
m application of lessons-learned, to avoid repeating past  offices/au/case-study-aus.aspx/, accessed February 20 13. 


mistakes 
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SUN Microsystems (now part of Oracle Corporation) 
United Nations 
Siemens 


Vodafone 


DHL Express 

Phillips 

Metropolitan Police (UK) 
HSBC (UK) 


many UK Government departments. 


PRINCE2 offers a comprehensive methodology with a defined process and distinct roles (which 
form an integrated set of governance guidelines) that can be tailored to any environment, whether 
complex or simple. See the Snapshot from Practice: PRINCE2—The Department of Parliamentary 
Services for an example of PRINCE2 being applied within a government department. 

As the next framework of ISO 21500:2012 is introduced, the reader should begin to draw some 
parallels, and to note some differences, between the approaches being covered. Note that PRINCE2 is 
documented in the official PRINCE2 guide available from AXELOS (https://www.axelos.com). 


2.4 AN OVERVIEW OF ISO 21500:2012 GUIDANCE 
ON PROJECT MANAGEMENT 


In November 2007, the International Organization for Standardization (ISO) began the development 
of ISO 21500:2012 Guidance on Project Management as an international approach and standard for 
the management of projects. To move development of the standard forward, a project committee 
(ISO/PC 236) was established, involving 20 countries in the development process, plus a further three 
observing. This standard had a large amount of interest from the outset, and in 2012, the first release 
was made public. (It is available from www.iso.org/iso/home/store.htm or via the SAI Global store in 
Australia at http://infostore.saiglobal.com/store/.) 

The standard takes account of project governance through a high-level process of interactions 
between the project management process and the organisational environment within which the project 
management process sits. Figure 2.5 outlines these processes. 

In ISO 21500:2012 there is an initial focus on positioning project management in the wider context of 
the organisation. Credit is given to the strategic alignment of projects (discussed further in Chapter 4) 
in terms of the alignment of the need for the project, from a top-down direction, not just the continued 
justification for the project in the form of a Business Case. The value creation chain outlined in the 
standard discusses the organisation’s strategy for identifying opportunities delivered by projects 
with defined benefits. The standard outlines the requirements for project governance among various 
groups of stakeholders, in particular, the governance arrangements between the project sponsor, 
the project steering committee and the project manager. It also sets out the relationships between 
portfolios, programs and projects, in support of organising the groups of investment opportunities 
that arise from the value creation chain. 

The main part of the standard focuses on the detail of the project management process (taking a 
familiar Predictive life cycle approach such as the one illustrated in Figure 2.2) with reference to the 
stages of Initiating, Planning, Implementing, Closing and Controlling. The ISO 21500:2012 project 
life cycle is illustrated in Figure 2.6. 

The Initiating process group is applied at the start of the project, or at each stage of the project, 
to open up discussion around whether a move towards a ‘stagebased’ project management approach 
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Figure 2.5 ISO 2 2 overview 
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is implied by the standard (rather than planning the project in its entirety at the Planning stage). 
This is likened to rolling-wave planning as introduced by PMI, where detailed planning for the next 
stage takes place at the start of that stage and not before. The detailed project planning documents 
and baselines (from which later project performance will be measured) are established within the 
Planning process group. The Implementing process group takes the plans and will be concerned with 
producing the project deliverables (i.e. executing the project plans). As indicated in Figure 2.6, the 
Controlling process group monitors progress and defines the manner in which change requests are 
managed and escalated. The Closing process group considers project management closure activities, 
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to ensure the stage/project has delivered the required objectives, including the stated outcomes and 
outputs of the project. 

The standard is similar in design to the PMBOK (PMD life cycle approach. The standard introduces 
the term ‘subject groups’, applied across the project life cycle. These subject groups have a shared 
commonality in terms of the material covered (albeit at a higher level than the PMBOK’s 10 areas of 
knowledge) and include: 


E I[ntegratien precesses: To ensure all knowledge areas are integrated in a holistic way, to manage 
the project across the life cycle. 


E Scepe precess: To ensure all/only the work of the project is defined. The deliverables are specified 
to enable the success of the project to be determined. 


Em Time precesses: To ensure the work is scheduled appropriately and is controlled to meet a 
scheduled completion date for the project. 


E Cest precesses: To ensure the project budget is established and can be controlled to satisfy 
completion of the project to budgeted requirements. 


E Quality precesses: Across both the management of the project and in the deliverables produced 
by the project. Quality control is to ensure defined project and deliverable criteria are met. 


E Reseurce precesses: To satisfactorily identify and allocate human resources and other resources 
(e.g. materials, facilities) to achieve the project’s objectives. 


E Precurement precesses: To support the acquisition of products and/or services required by the 
project and to enable these to be controlled and performance managed, according to contractual 
arrangements. 


Risk precesses: Using proactive identification, analysis and management of risk across the 
project life cycle process. 


Em Cemmunicatien precesses: To ensure that project information is generated, collected, distributed 
and managed across all aspects of the project. 


E Stakehelder precesses: To manage sponsor and other stakeholder needs and requirements 
including the management of issues and expectations across the project life cycle. 


The ISO 21500:2012 standard provides a useful highlevel standard (governance) for establishing 
a project management function within an organisation. In essence, it captures the ‘pre-project’ and 
‘initiating’ aspects of PRINCE2 and the ‘knowledge areas’ of PMBOK. 

The next methodology introduced is Agile (Scrum) project management. 


2.5 AN INTRODUCTION TO THE SCRUM APPROACH 


Agile project management (based on the original Scrum framework) was predominately used in 
software engineering, but this approach has now been adopted across many industries for many 
types of projects. Both PRINCE2 and the PMI have extensions on how to integrate Agile (Scrum) into 
their respective frameworks (as do others such as Praxis). Chapter 3 provides a detailed description 
of Scrum, which underpins the Agile way of working, without taking a vendor or specific body of 
knowledge approach (of which there are now many, as introduced earlier). 

According to The Scrum Guide, Scrum is based on the theory of: 


Transparency 

Significant aspects ef the precess must be visible te these respensible fer the eutceme. 
Transparency requires these aspects be defined by a commen standard se ebservers share a 
commen understanding ef what is being seen. 
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For example: 

E Acemmen language referring te the precess must be shared by all participants; and, 

E These perferming the werk and these accepting the werk preduct must share a commen 

definition ef ‘Dene’. 

Inspection 
Scrum users must frequently inspect Scrum artifacts and pregress teward a Sprint Geal te 
detect undesirable variances. Their inspection sheuld net be se frequent that inspectien gets 
in the way ef the werk. Inspectiens are mest beneficial when diligently perfermed by skilled 
ins‘pecters at the peint ef werk. 


Adaptation 

If an inspecter determines that ene er mere aspects ef a precess deviate eutside acceptable 
limits, and that the resulting preduct will be unacceptable, the precess er the material being 
precessed must be adjusted. An adjustment must be made as seen as pessible te minimize 
further deviatien (Schwaber & Sutherland 2017). 


Figure 2.7 outlines the Scrum approach and indicates: 


E the ‘re/es’—the product owner, Scrum master, development team and Scrum team 


Figure 2.7 The Scrum framework 
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E the ‘events’—the sprint, sprint planning meeting, daily Scrum, sprint review and sprint 
retrospective 


E the ‘artefacts’—the product backlog, sprint backlog, bundown/bumup charts, and finished work. 


Chapter 3 is dedicated to the Scrum (Agile) approach and provides a detailed narrative. Chapter 3 
also provides an overview on how Agile is considered by PRINCE2 and the PML 


2.6 AN INTRODUCTION TO THE APM FRAMEWORK 


Introduced as a certification arm of IMPA (predominately in the United Kingdom), APM also provides 
a competing body of knowledge based on the APM life cycle. The APM life cycle is illustrated in 
Figure 2.8. 

The phases of the APM life cycle are described as follows (adapted from APM 2012). 


E Cencept phase: This involves developing the initial idea (identify sponsor and project manager) 
including the outline Business Case. Providing the business with the ability to answer two key 
questions: Is the project likely to be viable? And is it definitely worth investing in the Definition phase? 


E Definitien phase: Identification of the preferred solution and the plan to achieve it, building the 
Project Management Plan (PMP). The PMP, together with a more refined Business Case, proceeds 
in the Development phase (upon approval). 


E Develepment phase: Executes the Project Management Plan, with stage reviews for each of the 
stages of the project carried out in order to ascertain the viability of moving into the next stage 
of the project. At the end of the Development phase, the project moves into Handover and Closure 
phase. 


m Handever and Clesure phase: The project’s outputs (and outcomes) are handed over to the 
business and are accepted by the sponsor on behalf of the business. 


E Finally, if benefits are realised at the end of the project, these are declared. 


Figure 2.8 The APM life 
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Further phases include: 
E Operatien: Continuing support and maintenance of the outputs in the business, and 


m Terminatien: Closure at the end of the product’s useful life. 


These two additional phases are important considerations in some industries, such as the 
construction of a nuclear power station, as there has to be a plan to decommission the plant (i.e. 
termination of the plant at the end of its useful life). 

The reader should note that APM is reviewing the APM Bok with the goal of publishing an updated 
Bok 7th edition in 2019. 


2.7 AN INTRODUCTION TO LEAN SIX SIGMA AND THE 
DMAIC PROCESS 


As introduced earlier, organisations taking a Lean Six Sigma approach to the development and 
maintenance of precesses (and all the holistic components of operating precess in the business) will 
use the DMADV and DMAIC processes to approach the project. 

DMAIC is by far the most predominant approach used for the improvement of processes and, as 
illustrated in Figure 2.9, each stage of the approach has defined outcomes: 


E Define is concerned with defining and understanding the problem and results in a Charter being 
produced for the project. The Charter validates at a ‘toll gate’ by the sponsor representing the 
business interests and a Lean Six Sigma Black Belt (a senior practitioner of the Lean Six Sigma 


Figure 2.9 The D 
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approach). Linking back the requirements to what the ‘customer’ of the process requires is 
referred to as the voice of the customer (VoC). 


Em Measure focuses on understanding the details of the existing process and coming to an agreed 
way of working. Once this has been ascertained, the ‘asis’ process can be baselined, against 
which future improvements made at the Improve stage can be measured. 


E Analyse is where the process and the data are analysed in detail, to ascertain root cause(s). 
The ‘process door’ looks at waste (in particular the eight wastes of transport, inventory, 
motion, waiting (delays), over-production, over-processing, defects and skills), Flow and 
Value (value-adding activities, nonvalue-adding activities, and business non-value-adding 
activities). Various visualisations of data are used from a ‘data door’ perspective. The results 
provide indications of improvement opportunities in the process under review, from which a 
root-cause analysis can be carried out. Two rootcause techniques are the ‘fishbone’ diagram 
and the ‘5 whys’. 


E Improve—once the root cause(s) has been confirmed, the process of identifying the best 
solution(s) to be implemented takes place; these are prioritised with input from the business. 
The selected solutions are developed ready for piloting (including the ‘tobe’ process and 
other artefacts, after which measuring takes place, to ensure the baseline established (at the 
Measure stage) has been improved upon. The solution will be implemented in the business 
after piloting and after further improvements have been made, as required. The implemented 
process is measured again post-implementation, to ensure the improvements being sought are 
actually achieved. 


E Centrel includes the activities of embedding the solution in business as usual (BaU) operations 
and leaving necessary measures and charts in place, including the all-important statistical 
process control (SPC) control charts. 


The Lean Six Sigma approach is highly problem oriented and typically generates only a 
few projectrelated documents such as the Charter, a Pilot Plan, an Implementation Plan and 
a Control Plan (which is handed over to the business during the Control] stage). Governance is 


SNAPSHOT FROM PRACTICE Lean Six Sigma at an Australian 


water company 





Seqwater (Queensland, Australia) is a large water service Each program has largely been developed 
provider in Queensland. It provides domestic drinking water independently to meet specific business needs and 
(plus water for irrigation) across Southeast Queensland. In regulatory requirements. In addition to independent 
recent years it has experienced significant organisational programs, data is also stored across multiple 
change through a series of mergers, throughout which it databases and systems. With the creation of the 
has still been required to deliver an efficient service to its Queensland Bulk Water Supply Authority (treding 
customers. A case study was carried out to demonstrate as Seqwater) there was an incentive to integrate 
how Lean Six Sigma could be applied to the water industry these programs. By taking a holistic approach to 
(using internal resources, leveraged by external consultants). water quality monitoring it is hoped that a better 


understanding of the schemes could be developed 


An area that was flagged as requiring a review __. (Howey & Middleton 2015), 


was externally provided with water quality and 


environmental monitoring. Seqwater’s current The project utilised a DMAIC process to manage the 
monitoring program is separated according to historic process improvement. Table 2.4 summarises the key 
business divisions, which are catchment, water activities undertaken at each stage of the DMAIC process 


treatment, bulk supply system ane environmental. by the improvement team. 
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Table 2.4 DMAIC at Seqwater 


Stage | Activities undertaken 


Define m Definition of the problem statement: ‘Through a series of restructures and amalgamations Seqwater’s combined 
water quality monitoring program has grown large. The rationalfe] behind the monitoring program needs to be 
reviewed in order to focus monitoring on achieving stated objectives in risk management and compliance. It is 
considered with a more focused monitoring program significant savings could be achieved’ (Howey & Middleton 
2015). 

m Clarification of the project's scope, along with identification of the project’s key objectives of identify efficiencies, 
improve risk management, maintain regulatory compliance and fulfil contractual (other monitoring) commitments. 

m Listening to the voice of the customer, with the customer being represented through regulatory and other 
requirements reviews, benchmarking to other water providers, and a focus group workshop. 





Measure m inorder to baseline (measure) the current (as is) process, the improvement team had to understand the ‘as-is’ 
process of routine and non-routine sampling and analysis. ‘Historic financial information was gathered for all of the 
components of the program. In addition to this the current documented routine monitoring program was costed, 
which included 61 test suites and over 220,000 analyses per annum’ (Howey & Middleton 2015). 

m ‘Risks’ across 40 water treatment plants were also collected, in addition to financial data. If this risk data had 
not been available, the project could have carried out a current analysis of risk (of the as is process) using a 
technique known as a FMEA (failure mode and effects analysis). 

Analyse m “A vital question that [the] project needed to answer was whether the monitoring data collected actually fulfilled 
the rationale that justified the monitoring in the program (i.e. was it being used and was it valuable)’ (Howey & 
Middleton 2015). 

m The improvement team used a popular Lean Six Sigma data analysis tool (Minitab) to visualise the various critera 
of water quality using charts such as boxplots, graphical summaries, interval plots, correlation (scatter graphs) and 
Pareto charts. 

m Root causes (findings) were taken forward from the Data Analysis stage (carried out in the Analysis stage) to the 
Improve phase of the project. 

Improve m Recommendations (solutions) were made and developed for each finding. These recommendations were 
subsequently applied to atest site and (following measurement) were considered for deployment to the entire 
montoring program. 

Control m The control processes, measurements and the tool used (Minitab) were all passed back to Seqwater for further 
consideration. 

m The project's success was considered: ‘Based on these changes the routine analysis budget was reduced by 
45%. However, even if all the recommendations were to be applied it is not anticipated that a final saving of this 
magnitude would be achieved, as there will be an increase in non-routine monitoring as the program moves to a 
more risk-based approach and a considerable cost still exists for sample collection’ (Howey & Middleton 2015). 

m This open and transparent declaration, regarding its final impact, provided an example of an important 
understanding of Lean Six Sigma projects. 


Source: (c) James Howey, Duncan Middleton - Viridis Consultants P/L, Brisbane and Seqwater, Ipswich 


In the conclusion to the paper, the authors note that: This Lean Six Sigma project example demonstrates 
the focus of such projects: the majority of effort was 
focused around the project, analysis and later solutions 
for implementation, rather than a heavy focus on the 
project management aspects (as in Predictive project 
management approaches). This is one of the reasons 
that the uptake of Lean Six Sigma practices has grown 
significantly across the globe. 


Statistical analysis showed in many cases that 
the rationale for monitoring was not being 
demonstrated by the results and value for money 
was not being achieved. Recommendations for 
improvement were applied to Seqwater’s routine 
monitoring program, removing high cost low risk 
monitoring and a saving of up to 45% was possible, 


hilst still maintaining regulatory compliance and 
w n g reg y mR Source: Howey J & Middleton D 2015, ‘Lean Six Sigma application to water 


effective risk management (Howey & Middleton utilities: getting value for money out of water quality monitoring’, Technical 
2015). paper. wwwawa.asn.au/documents/068%20JHoweypef, accessed February 
2018. 


contained in the toll gates, which give the go-ahead to move into the next stage of DMAIC. DMAIC 
projects can be of any reasonable length of time (e.g. from days, months for larger, more complex 
improvement projects). The environment is very agile when applying DMAIC, as tehniques suchas 
the Kanban board (story board in Scrum), daily standups (daily Scrum) and self-managing work, 
are applied—refer Snapshot from Practice: Lean Six Sigma at an Australian water company. 
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2.8 AN INTRODUCTION TO THE PRAXIS FRAMEWORK 


The Praxis framework is an open source project management method that draws from different 


bodies of knowledge to provide a consistent framework for project management. The Praxis project 


management approach (which also considers programs and portfolios in its wider framework) is 
illustrated in Figure 2.10. 
The process groups are described as follows. 


The identification process manages the first phase of the project’s or program’s life cycle. Its 


goals are to: 


develop an outline of the project or program and assess whether is it likely to be justifiable 
determine what effort and investment is needed to define the work in detail 

gain the sponsor’s authorisation for the definition phase. 

This process is designed to achieve the goals of the sponsorship function, which are to: 
provide ownership of the Business Case 

act as champion for the objectives of the project or program 

make go/no-go decisions at relevant points in the life cycle 

address matters outside of the scope of the manager's authority 


oversee assurance 


provide ad hoc support to the management team. 


Figure 210 The Praxis approach 
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The definition process manages the definition phase of the project or program life cycle. Its 
goals are to: 
develop a detailed picture of the project or program 
determine whether the work is justified 


describe governance policies that describe hew the work will be managed 


gain the sponsor's authorisation for the delivery phase. 


An authorised brief and definition plan will trigger the process (which is fundamentally the same 
regardless of whether it has been decided to govern the work as a project or a program). The output 
will be a set of documents describing all aspects of the work with their content and detail varying to 
suit the context. 

The delivery process of a small preject may comprise only one stage. The delivery phase of a 
pregram may comprise only one tranche. Most projects and programs will comprise multiple stages or 
tranches that. are conducted in a series or in parallel. 

Whatever the context, managing each stage or tranche will involve following a basic ‘plan, do, 
check, act’ cycle sometimes known as the Shewhart cycle (similar to the DMAIC cycle mentioned 
previously). In the delivery process: 


E ‘plan’ becomes ‘authorise work’ 
‘do’ becomes ‘coordinate and monitor progress’ 


‘check’ becomes ‘update and communicate’ 


‘act’ becomes ‘corrective action’. 
The geals of delivering a project or program are then to: 


delegate responsibility for producing deliverables to the appropriate people 
monitor performance of the work and track this against the delivery plans 
take action where necessary to keep work in line with plans 

escalate issues and replan if necessary 


accept work as it is completed 


maintain communications with all stakeholders. 


The closure process goals are to: 


close a project or program that has delivered all of its outputs 
close a project or program that is no longer justifiable 


@ review the management of work and learn ‘lessons’. 


Closure is principally concerned with a temporary organisation (the project) handing over 
responsibility for its objectives and disbanding. Where that occurs in the life cycle will depend on how 
the project or program was constituted in the first place. 

The benefits realisation process—It is usually the case that benefits are not automatically realised 
simply by producing an output. In most cases, an output is used to change some aspect of an organisation’s 
mode of operation, or environment. Implicit within the word ‘change’ is a quantifiable improvement in 
one or more performance indicators to which value has been assigned. The goals of this process are to: 


Æ establish the current state of what is being changed 


@ co-ordinate the delivery of outputs with the management of change 
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Figure 2.11 
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Source: Adapted from ‘Using Scrum with Praxis’, Praxis, https://www.praxisframework.org/en/resource-pages/using-scrum-with-praxis, 
accessed February 2018 


m ensure changes are permanent 


E establish whether benefits have been achieved. 


In its simplest form, realising benefits is about measuring current performance, helping people who 
make up the organisation through the period of change (the transition) and measuring the improvement. 
in performance. (Adapted from: https://w ww.praxisframework.org/en/method/identificationprocess.) 

Praxis (much like PRINCE2 and the PMI) supports the integration of Agile in the delivery process 
of the life cycle. As illustrated in Figure 2.11, the ‘delivery process’ is broken down further, with 
the Agile approach effectively replacing the traditional approach. Chapter 3 has similar diagrams, 
indicating how the Agile elements integrate with the PRINCE2 and PMI life cycles. 


2.9 AN INTRODUCTION TO PMBOK 


To further develop understanding of PMB@K, let’s now look at a brief history of PMI’s PMB@K. A Guide 
to the Project Management Body of Knowledge (known as PMB@K) was first published as a white 
paper in 1983 to document and standardise generally accepted project management information and 
practices. The first edition of PMB@K was published in 1996, followed by the second edition in 2000. 
PMB@K received a major overhaul with the release of a third edition in 2004 and this was subsequently 
built upon in the fourth edition, released in 2008. The latter two editions gained in popularity when 
supporting certification and education programs became a major drawcard for achieving the Project 
Management Professional (PMP) certification. 

The fifth edition of PMB@K was released in January 2013 with some Agile considerations. In 2017, 
the sixth edition of PMB@K was released and included extensive consideration of the Agile approach 
and was supplemented with an additional guide: the Agile Practice Guide, which took Scrum/Agile 
theory and indicated how this can be leveraged within the PMB@K life cycle. 

Chapter 3 explores the PMPs Agile implementation and looks at how it can integrate with the PMI's 
life cycle. 


PART 1 SETTING THE SCENE 


Figure 2.42 Pr 
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The PMBOK life cycle was introduced in Chapter 1, Figure 1.2 and this will now be explored further. 
Figure 2.12 presents the stages of the life cycle in a more traditional format. The process groupings 
indicated in Figure 2.12 are described as: 


= Initiating process group: The processes carried out in relation to the definition of a project (or 
project stage), generating an approved project Charter. 


m Planning process group: The processes carried out in relation to defining the detail required 
prior to executing the plan (or stages), further clarifying the Charter as a scope document, and 
the development of the integrated Project Management Plan. 


m Executing process group: The processes carried out in relation to completion of the planned 
work according to the approved Project Management Plan. 


m Closing process group: The processes (or stage) carried out in relation to formally closing the 
project (or stage). 


= Monitoring and Controlling processes group: The processes carried out in relation to the 
review, tracking, reporting and management of change (variations) across the life cycle of the 
project (or stage). 


2.9.1 Applying the life cycle approach 


It is important to consider hew a project manager might leverage the PMBOK life cycle approach in 
the design (approach) of the project. It is perfectly feasible and normal to phase a project. Phases of 
a project are natural separations in the work to be performed, often occurring where approvals need 
to be sought. before proceeding onto the next phase of the project. PMBOK outlines three ‘phased’ 
approaches: sequential relationship, overlapping relationship and Iterative approach. 

Sequential relatienship: Sequential relationship, where one phase of a project can only start on 
completion of a previous phase, is depicted in Figure 2.13. In this figure, Phase 1—Design factory must 
complete before Phase 2—Acquire and prepare land, and Phase 3—Build and commission factory can 
only start after Phase 2 has been completed. Note, each phase is in itself a complete life cycle from 
Initiation to Closure. 
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Figure 2.13 Sequential-phased approach 
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Overlapping relationship: Is when a future phase of the project can start before a previous 
phase has completed, as shown in Figure 2.14. In this figure, although Phase 1—House design must 


complete before Phase 2—House build starts, it can be seen that Phase 3—Landscaping can start 
during Phase 2. 


Figure 2.14 Overlapping-phased approach 
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Figure 2.15 
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Iterative appreach: Iterative approach is where the next phase is planned (and influenced) by the 
current phase, as the current phase is being delivered, as depicted in Figure 2.15. In this figure; while 
Phase 1—Factory design is being delivered, Initiating and Planning processes are taking place on 
Phase 2—Acquire and prepare land. However, Phase 3—Build and commission has not yet received 
much consideration until Phase 2 has closed. Remember, the principle of rolling wave planning is a 
progressive elaboration. Therefore, project work can exist in various levels of detail, depending on 
where it is in the overall project life cycle. 


2.9.2 Integrative project management 


The importance of taking an integrative approach to the 10 knowledge areas cannot be stressed enough. 
The project manager may focus on a particular area of the project, however a ‘good’ project manager 
will ‘play’ the consequences of any decisions made across all the other knowledge areas. 

For example, you may be a project manager who is in the Initiating stage of the project when the 
customer requests a change to the enddate of the project to bring it forward by a number of weeks. 
As project manager, your decision cannot be made purely on time; adjusting the delivery schedule 
will necessitate a review of many factors, including resource availability, additional equipment 
expenses, potential effects on the quality of the outcomes and the changes to the risk profile of the 
project. 

As with ISO 21500:2012, a similar approach is taken to the linkage of the process groups across the 
10 areas of knowledge. 
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Note: The reader is advised to review PMB@K’s process groupings and 10 areas of knowledge in 
the Project Management Institute (PMI) 2017, A Guide to the Project Management Body of Knowledge, 
6th edition, PMI, p. 64. 

Note that this text builds the integration aspects and discussion around what activities are taking 
place within each stage of the project life cycle, into the relevant knowledge chapter. The reader 
will therefore not see a specific chapter on Initiation, Planning or Execution, but rather a number of 
knowledge chapters with the Initiation, Planning and Execution stage components of the life cycle 
discussed within each chapter. A discussion of the more formal aspects of project integration takes 
place in Chapter 7. 


2.9.3 Governance and gates 
Governance is achieved in PMB@K across the project life cycle via two key techniques: 


E First, a subsidiary management plan (a project management document that focuses on the 
process, procedures and governance aspects of a particular knowledge area) is developed. 
The Management Plan should highlight governance that is relevant to that knowledge 
area, considered across the process groupings. For example, the Communications 
Management Plan could contain a Responsibilities Matrix that details who is responsible 
for writing, proofreading and approving various classes of communications generated 
from the project. 


E Second, the project life cycle will include a number of gates (when integrated into the 
organisation's portfolio and program management processes). These gates are often referred 
to as phase exits, decision gates, decision points, stage gates, gateway reviews or kill 
points. A typical gated scenario is illustrated in Figure 2.16: 


E Gate 1 could be a project management office (PM®@) ‘pre-approval gate’ required for the project 
to proceed. 


E Gate 2 could be a steering committee ‘approval gate ’ seeking confirmation of the project 
Charter and that the original Business Case is still valid, or where the release of funds would be 
approved for the Planning stage to be initiated. 





Monitoring and controlling 
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Gate 3 once more could be a similar steering committee approval gate—where detailed plans are 
approved and monies released for the project to progress to the Execution stage. 


Gate 4, at the end of the Execution stage, would be the required verification of deliverable 
acceptance, before formal project closure is initiated. 


Gate 5 could be a governance, benefit and final post-implementation review assessment. The 
gated process would be adjusted to suit the governance established at project initiation and 
would be influenced by governance around benefit management, Business Case validity and any 
relevant PMO governance. 


2.9.4 PMBOK 6th edition key updates 
Some of the key changes in PMBOK 6th edition, include: 


project time management renamed to ‘project schedule management’ 

project human resource management changed to ‘project resource management’ 
process ‘manage project knowledge’, added 

process ‘estimate activity resources’, moved to project resource management 
process ‘control resources’, added 

process ‘implement risk responses’, added 

process close procurements, eliminated — just becomes a ‘closure activity’ 
perform quality assurance, renamed ‘manage quality’ 

plan human resource management, renamed ‘plan resource management’ 
acquire project, renamed ‘acquire resources’ 

develop project team, renamed ‘develop team’ 

manage project team, renamed ‘manage team’ 

control communications, renamed ‘monitor communications’ 

control risks, renamed ‘monitor risks’ 

plan stakeholder management, renamed ‘plan stakeholder engagement’ 
control stakeholder engagement, renamed ‘monitor stakeholder engagement’ 
a new risk response ‘escalate’, introduced 

addition of tailoring, Agile and trends to each knowledge area 

new EVM calculation, ‘ES’ (earned schedule) 


the further embedding of PMI talent triangle (technical project management, leadership, strategic and 
business management) as the more holistic approach to the skills required by project managers. 


These organisationally aligned gated processes are established at. project startup. In most 


cases the governance process around approvals and funding will already be established within the 


organisation (typically a role of the PMO). The project manager must identify these processes and the 
interactions of their project to them. 


The project management office (PMO) is a department within the business that defines project 


management standards, methodologies and governance. It often manages the portfolios and the 
programs. The PMO should be able to assist the project manager in tailoring governance to the 
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project environment. The project manager subsequently documents these arrangements within the 
Integration or Scope Management Plan, including details of the committees, committee charter, and 
the governance roles and responsibilities of the committees. 

Note the difference between this and PRINCE2, where governance is built into the methodology 
through the interactions of the Directing a Project (DP) process and in the tightly defined roles and 
responsibilities of predefined project and executive roles. PMBOK is a generic approach to project 
management: its strengths rest in its 10 knowledge areas—this knowledge being foundational and 
applicable to almost any other project management framework or methodology. 


2.9.5 PRINCE2 and PMBOK compared 


As PRINCE2 and PMBOK frameworks are still the most commonly found in practice, a useful additional 
summary of these two approaches is provided in Table 2.5 (given there are benefits in both). The 
summary table deliberately uses commonly encountered terminology as is often found in practice. 
Although succeeding chapters of this text will unpack this terminology, it is offered here by way of a 
sample so the reader can begin to familiarise themselves with it. 


Table 2.5 Comparison of PMBOK and PRINCE2 


PMBOK PRINCE2 


Knowledge-based: PMBOK is a body of knowledge 
underpinned by a simple life cycle approach. 


Focus on trade-offs between scope, time, cost and 
quality: captured in the scope document. 


Builds in team management and leadership. 


Allows for the definition of quality and integrations across 
the life cycle. 

Provides a rich set of tools for time management in terms 
of WBS, schedules, tracking (Gantt charts) and networks: 
activity on node (AON) and activity on arrow (AOA). (See 
Chapter 9.) 


Change management is used as a control mechanism. 


Lessons-learned are less emphasised and are left to the 
project manager to decide on inclusion in the life cycle 
approach. 


Governance has to be established by the project 
manager in conjunction with the PMO and sponsor, often 
captured in the Roles and Responsibility Matrix. 


PMBOK is flexible in its approach and structure. 


Process-based: PRINCE2 is a highly structured method 
for the management of projects across any environment 
and industry. 

Focus on the continued justification of the project and the 
Business Case. 


Has tightly defined roles and accountabilities of these 
roles. 

Has defined roles for quality management and its 
validation throughout the project. 

Assumes knowledge of the tools in relation to time 
Management and focuses more on the management of 
products. 


Exceptions to plan and the management of exceptions 
through the methodology are used to control and verify 
(via the tightly defined roles)—the focus is on deviations 
from plan. 


Lessons-learned are encapsulated in the methodology. 


Governance (roles and accountabilities) are defined 
within the methodology and each role in the project 
(including executive management) is tightly defined. 


Has a defined structure and process which can be 
tailored, but only within the bounds of PRINCE2. 


Summ 


There are many project management frameworks and methodologies available to a project manager. This text has 
focused on some of the more popular, commonly used methodologies including PRINCE2, ISO 21500:2012, Agile, 
Lean Six Sigma, APM, Praxis and PMI’s PMBOK. However, there are no hard and fast rules around which frameworks 
and which methodology should be used. There are some noticeable patterns, however, which can potentially assist 
with demonstrating the usage of one methodology over another. 


m PRINCE2 was, historically, principally used by governments and for large commercial ICT projects or by large 
corporations. It is characterised by strong governance and a continued business justification throughout the project. 
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ISO 21500:2012 offers emerging guidance where the adoption of a standard-based approach to project 
management at a high level is sought. It is ideal for when businesses require only high-level guidance to establish a 
ro ject management presence supplementing the detail behind the guidance with other approaches, such as PMI or 
Praxis. 

Scrum (Agile) is the approach of the moment as organisations seek more agility in the management of projects, 
uilding only features that deliver value to the business. This approach is based on a small number of roles (product 
owner, Scrum master and development team), a few events (sprint planning, daily Scrum, sprint review and sprint 
retrospective) and a small number of key artefacts (product backlog, sprint backlog, burndown/up charts and the 
inished product). It provides a principles-based approach to the management of projects that have uncertain 
requirements and/or are complex. 

Lean Six Sigma is an approach that is gaining a lot of traction for the ongoing continuous improvement of processes. 
tis administered through the ‘belt’ system of roles: a Yellow Belt (for a subject matter expert (SME)), a Green Belt 

(for a project lead) or a Black Belt (for a more senior role e.g. complex project lead). It has some Agile concepts, is 
customer- and problem-focused, and does not have a large project management footprint. 

APM is an approach that remains popular as an alternative to the PMI’s PMBOK. Although the APM Body of 
Knowledge (6th edn) is not as content-rich per se, its overarching process encompasses the key elements of the 
extended project life cycle and the product life cycle required in the modern project management approach. 

Praxis is the open source portfolio, program, and project management approach. Although just entering mainstream 
project management, it is built on community-based empirical evidence from practising project managers and on a 
solid body of support knowledge, templates, and other artefacts. 

PMBOK is a generic, de facto, project management framework. It is applied across all industries (private and 
government) and is supported by a rich knowledge-based approach. It takes a truly global approach towards project 
management and offers easily-accessible training and education programs. PMBOK is often adapted and internalised 
within organisations and supported by other business processes and governance (such as procurement or human 
resource processes and policy) to provide a wide, comprehensive methodology. 








Deciding which framework or methodology to use is often not a simple process and this decision can be influenced 
by any number of factors, including: 

the project management maturity of the organisation 

the presence of any partially inplemented project management methodologies already in place within the 
organisation 

methodologies being adopted in the organisation's supply chains 

methodologies predominately utilised by customers or clients 

the maturity of business processes that support project management, such as business case development and 
approval, business planning and investment prioritisation 

the degree of customisation and internalisation versus the acceptance of a common industry-led approach to project 
management 

project management skills available in the marketplace 

the agility of the organisation 

the stability of requirements. 


To assess which methodology will bring the greatest benefits to the organisation, a Business Case should be 
developed. The Business Case should focus on which framework to adopt. It should outline all viable approaches 
available to the organisation and include details of the relative benefits of each approach, as well as the costs 
(financial and organisational) of implementing and embedding the project management methodology into the 
organisation. Locating and citing research to support the choice of a preferred approach is of course important. 


KPMG’s 2017 project management survey indicates the following distribution of project management approaches: 


PRINCE2 54 per cent 
inhouse methodologies 52 per cent 
Agile 43 per cent 
PMBOK-based 30 per cent 
other methodologies 4 per cent. 
The data reveals that the use of Agile has increased by 43 per cent since the last survey was carried out in 2013. 
KPMG comments: 
itis hardly surprising that agile methods are becoming more and more popular as organisations seek to 


respond faster and more effectively to an increasing pace of change, especially in the way they manage 
projects that produce improved ways of working or new products. (KPMG 2017) 
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Chapter 3 takes an in-depth look at the Scrum (Agile) approach, and subsequent chapters look at each of the 10 
areas of knowledge in more detail, since they: 


form large sections of PMBOK and other competing bodies of knowledge 

underpin the many competency-based certifications that exist globally (such as IPMA, AIPM, APM and many others) 
form the knowledge component of formal qualifications (such as the Australian VET sector Certificate IV, Diploma, 
and Advanced Diploma in Project Management). 


https://www.projectmanagement.com/articles/278600/Why-Youre-Confusing-Frameworks-with-Methodologies 
www.agilealliance.org 
https://www.APM.org.uk 
www.apmg-international.com 
https://www.axelos.com/certifications/prince2 
www.ipma.world 
www.iso.org/iso/home/store.htm 
https://www.praxisframework.org 
www.projectmanagementinpractice.world 
www.minitab.com 

https://www.apm.org.uk 
https://www.agilebusiness.org 
https://www.scaledagileframework.com 
https://less.works 
https://www.scrumguides.org 
https://www.iso.org/standard/50003.html 


https://www.gov.uk/government/publications/best-management-practice-portfolio/ 
about-the-office-of-government-commerce#links 


https://hbr.org/ 1986/01/the-new-new-product-development-game 


Adaptive life cycle outcomes Project Management Body of 
Agile Project Management (APM) outputs Knowledge (PMBOK) 
gates (phase exits, decision gates, Praxis rolling wave planning (iterative 
decision points, stage gates, Predictive life cycle planning) 
gateway reviews or kill points) PRINCE2 Scrum 
Incremental life cycle product backlog Scrum master 
ISO 21500:2012 product owner Sprint backlog 
Iterative life cycle project governance valuable body of knowledge 


Lean Six Sigma 


Review questions 


41. Why is a traditional project management approach less effective when project scope and technology are not well 
known? 


5 


What are the four types of approaches to project management? Explain briefly and draft a diagram. 


w 


What are the advantages of Agile? What are the disadvantages of Agile? 


A 


How does Praxis integrate Agile into its project management approach? 
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5. Why does the project manager need to think beyond the project as captured in a number of the approaches 
described in the chapter? 


6. Why does ISO 21500:2012 appeal to organisations that have limited project management experience? 
7. What are the 10 knowledge areas within the PMI Body of Knowledge? 
8. What do all the methodologies have in common in relation to knowledge? 
9. What factors influence the selection of one approach over another approach? 
10. What type of project(s) is the Lean Six Sigma approach best suited for? 
11. What tools exist to assist in the selection of a project management approach? 


4. (a) Break into small groups and identify at least two real-life examples of projects in which: 
{i) The scope and technology are well known. 
{ii) The scope is well known, but the technology is less well known. 
qiii) The scope is not well known, but the technology is known. 
(iv) Neither the scope nor the technology is well known. 
{b) For each of the above projects, make a new recommendation for the best project management approach to use. 


2. Break into small groups and discuss the following question: What organisational, group, individual and project factors do 
you think would promote the successful adoption of a PMBOK-based life cycle? Why? 


A case study relevant to this chapter, Introducing Scrum at P2P, is available online. 
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Q Setting the scene 
Modern project management 
Popular frameworks and methodologies 
(2) Positioning projects 
The Scrum (Agile) approach 
Organisational strategy and project selection 
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Project integration management 
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Project schedule management 
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Project resource management 

The project manager and project teams 
Project stakeholder management 
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management 


Project risk management 
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Learning elements 


Understand the history of Scrum and Agile and the key thinking behind the Agile 
(Scrum) approach. 


Gain an understanding of the Scrum approach, roles, events and artefacts. 
Understand the details of the Scrum roles. 

Understand the details of the Scrum events. 

Relate the concepts of epics, increments and sprints. 

Understand the details of the Scrum artefacts. 

Learn how Scrum can be scaled. 


Relate Scrum practices to the developing DevOps approach. 


In this chapter 


3.1 Introduction 

3.2 Overview of Scrum 

3.3 Scrum roles 

3.4 Scrum events 

3.5 Epics, increments and sprints 

3.6 Scrum artefacts 

3.7 Scrum (Agile), PRINCE2 and PMBOK 
3.8 Large-Scale Scrum (LeSS) 

3.9 DevOps 


Summary 
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3.1 INTRODUCTION* 


The term ‘Scrum’ was introduced in a Harvard Business Review paper titled, ‘The new new product 
development game’ (Takeuchi & Nonaka 1986). In this paper, the authors observed that projects that 
use small, cross-functional teams historically tend to produce the best results. They relate such high 
performance teamwork to rugby ‘scrum formations: 


Companies are increasingly realizing that the old, sequential approach to developing new 
products simply won't get the job done. Instead, companies in Japan and the United States 
are using a holistic method—as in rugby, the ball gets passed within the team as it moves as 
aunit up the field. 

This holistic approach has six characteristics: built-in instability, self-organizing project 
teams, overlapping development phases, ‘multi-learning,’ subtle control, and organizational 
transfer of learning. The six pieces fit together like a jigsaw puzzle, forming a fast, flexible 
process for new product development (Takeuchi and Nonaka 1986 ). 


Scrum was one of the earliest implementations of the new product development game that emerged 
out of this work. Jeff Sutherland set about formalising and realising this new way of working by 
applying it to software product development. Using the study by Takeuchi and Nonaka as a 
platform, Sutherland published Scrum: The Art of Doing Twice the Work in Half the Time (1998). 
Ken Schwaber—software developer, product manager and industry consultant—is also associated 
with the development of Scrum. He presented Scrum as a formal development process at an OOPSLA 
(ObjectOriented Programming, Systems, Languages and Applications) conference in 1995. 

In 2001, the Agile Manifesto (a formal declaration of four key values and 12 principles towards 
an iterative and people-centric approach to software development) was born. This started the ever- 
expanding world of Agile and since then, many other variants of Scrum have emerged, including: 


Kanban: based on the Toyota Production System (commonly known as Lean Thinking) 
XP or eXtreme Programming 


Scrum of Scrums 


LeSS or Large Scale Scrum 
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E Dynamic System Development Model (DSDM), a formalisation of the Rapid Application 
Development (RAD) methodology 


E SAFe: Scaled Agile Framework. 


Based on the early work of the Agile Alliance, Ken Schwaber and Jeff Sutherland came together and 
published a compact guide to the (now globally accepted) Scrum approach, titled The Scrum Guide 
(available at: www.scrumguides.org). 

In recent times, these approaches have been supplemented by enhancements to two globally 
accepted frameworks on project management: PRINCE2 (AXELOS, 2017) and the Project Management 
Institute’s (PMI) Preject Management Bedy ef Knewledge (PMI 2017a). 


3.1.1 So what is Scrum? 
According to Schwaber & Sutherland (2017), Scrum is: 


Aframewerk within which peeple can address complex adaptive preblems, while preductively 
and creatively delivering preducts ef the highest pessible value. 
[It] is: 


m Lightweight 
m Simple te understand 


a Difficult te master. 


The Agile Manifesto consists of the manifesto and a set of accompanying principles. The reader is 
encouraged to review the manifesto (see http://agilemanifesto.org). 

The items in the manifesto are seen as critical to the successful implementation of Agile, Scrum 
and all its variants. They underpin the essence of the style of Agile projects. The manifesto is further 
supported by an expanded set of principles, as outlined in In Theory: Principles behind the Agile 
Manifesto (see http://agilemanifesto.org/principles.html). 

(Nete: The reader is advised to review both the manifesto and principles in their original form, as 
these form an important basis to understanding the intent of the Scrum and Agile movement.) 

In 2014, the Dynamic Systems Development Method (DSDM) released the latest version of their 
variant of the Scrum/Agile approach in the DSDM Agile Project Framework. At the same time, the 
new DSDM manual recognised the need to operate alongside other frameworks for service delivery 
including ITIL, PRINCE2, Managing Successful Programmes, and the Project Management Body of 
Knowledge. The previous version had only contained guidance on how to use DSDM with the eXtreme 
Programming (XP) development approach. 

The original Scrum guide was further updated in 2017. ‘Values’ were included in support of the 
successful application of Scrum, with the fellowing comment: 


When the values ef commitment, courage, fecus, epenness and respect are embedied and lived 
by the Scrum Team, the Scrum pillars ef transparency, inspectien, and adaptatien ceme te 
life and build trust fer everyene. The Scrum Team members learn and explere these values as 
they werk with the Scrum reles, events, and artifacts. 

Successful use ef Scrum depends en peeple beceming mere preficient in living these five 
values (Schwaber & Sutherland 2017). 


Scrum (and its iterations) have developed over time based on the Agile manifesto and its principles, 
meaning that Scrum has grown from deep, empirically based, strong roots. Its practice reaches out 
across many industries and some of the reasons behind its success will be revealed as we next take a 
look at how Scrum works in practice. 
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3.2 OVERVIEW OF SCRUM 


The Scrum framework is often said to be simple to understand, yet the secret to its use lies in all its 
nuances. Figure 3.2 represents an often-seen articulation of the Scrum framework and its components. 
This figure will be referred to throughout this chapter as each component (the roles, events and 
artefacts) of the Scrum framework are introduced and discussed. 

An outline of each of these components is introduced in the fellowing sections, together with 
practical examples to facilitate understanding. These sections will cover the: 


E Scrum roles—product owner, Scrum master, development team and Scrum team 
E events—sprint, sprint planning meeting, daily Scrum, sprint review and sprint retrospective 


E artefacts—product backlog, sprint backlog, burndown/eurnup charts and finished work. 


By breaking down each of the components, it becomes clear how these ultimately come together as an 
approach for the management of project work and how this approach can supplement more traditional 
approaches such as PRINCE2 and the A Guide to the Project Management Body of Knowledge 
(PMI 2017a). 


re 3.2 The Scrum framework 
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3.0 SCRUM ROLES 


Aspects of the various roles found within Scrum can be difficult for some organisations to grasp. 
This is especially true in organisations used to having management teams that are arranged around 
traditional project management roles such as project managers, team leads, schedulers, business 
analysts, architects, coders and testers (to name but a few). 

The first step in gaining acommitment to Scrum is to accept that there is no formal project manager 
and that the skills of traditional roles such as coders, testers and business analysts are considered as 
being overarching skills that are required by the development team to achieve the goals of a particular 
sprint being attended to. 

The three roles involved in Scrum are: the product owner, the scrum master and the development 
team (often referred to as the dev. team); each of these roles will next be explored. 


3.3.1 The product owner 


The product owner (a single accountable person, not a committee) is responsible for driving value out 
of the product under development. Remember that a product could be a software product or physical 
product—this is the value of Scrum (i.e. we can apply the framework beyond the ICT (information and 
communication technology) domain, as promoted by the originators, Takeuchi and Nonaka). 

The product owner is responsible for: 


E managing the product backlog 
ordering (prioritising) the items on the product backlog 


E ensuring a product roadmap (refer to Figure 3.25 in the case study at the end of the chapter) 
exists and that it is considered in the ordering of items 


Em ensuring wider organisational goals and missions (also considered in the ordering of items) 
E optimising the value of the work to be performed by the development team 


E ensuring the product backlog is visible the business and in doing so, becoming a collection/ 
negotiation point for requests from the business and ensuring the business is aware of the 
ordering (prioritisation) of requests that will be fed into the sprint planning meeting 


Em ensuring the development team understands the items on the product backlog and acting asa 
conduit for questions about the items on the product backlog 


E representing the needs and requests of any committees (for example, user group committees), to 
the Scrum environment. 


The product owner may delegate aspects of their role to the development team. However, at all times, 
they remain accountable for these rolespecific duties. In practice, better business accountability is 
often observed if the product owner does take on a more active role and retains the duties as advised. 
Therefore, the product owner must be willing and able to make regular representations and allocate 
dedicated time to the management of the product backlog. 

The business must respect the role of the product owner and empower the person in this role to 
make all required decisions (often on a quick turn-around basis). For example, no one in the business 
can change or override a set of items agreed with the development team; they must go through the 
product owner to make any changes. 


3.3.2 The Scrum master 

The Scrum master must be an independent overseer of the Scrum framework including executing its 
values and principles. Their role is probably the most difficult to achieve in practice as this is not a 
project manager role. Their focus is to build confidence in the use of Scrum practices. 
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Activities included in the Scrum master’s role encompass: 


E promoting all aspects of the Scrum Guide (theory, practices, rules and values as outlined in this 
chapter) 


actively using the servant leadership style of management (refer to Chapter 14) 


understanding Scrum deeply and being able to adjust the behaviours of the business, the product 
owner and the development team accordingly 


helping in planning Scrum iterations (sprints) at the sprint planning meeting 
enabling changes to the environment to promote Scrum practices (e.g. the colocation of Scrum 


team members and protecting the development team from unnecessary interruptions such as 
wallcups by employees in the business) 


@ working with other Scrum masters to take lessons-learned from all Scrums into the Scrum 
environment to ensure the Scrum team (including the development team) is working as 
effectively and efficiently as possible. 


They assist the product owner by: 


@ ensuring the whole Scrum team (master, product owner and development. team) understand the 
product context, domain and roadmap 


m advising about the techniques (and tools) needed for the management of the product backlog 
with the product owner, to ensure a consistent approach is applied and practised 


@ helping the product owner by ensuring the items on the product backlog are clear and devolved 
toa consistent level of articulation 


™ assisting the product owner in continually reviewing (formerly known as ‘grooming’) the list, as a 
result of changes to the business environment and from the work carried out by the development 
team (often referred to as empirical, because it is updated given the circumstances in both these 
environments and will change accordingly) 


@ helping the product owner in the ordering (prioritisation) techniques of the items in the 
list whether MoSCoW or another prioritisation technique is used. (Refer to In Theory: The 
MoSCoW Prioritisation Technique). With the ongoing ordering and reordering of items (and 
potential constant changes to ordering), the Scrum master is essentially promoting ‘agility’— 
items are not fixed until they are agreed to be the content for a sprint (and even could change 
although generally this is not advisable). Prioritisation is an important concept as it assists the 
business in determining the highvalue items that should be attended to first. For example, if a 
product owner sees a lot of value (benefits) in implementing workflows in a Human Resource 
Management System, then these features would be given a higher priority in the product backlog 


™@ assisting the product owner to understand the Scrum events (or at the request of the product 
owner to even facilitate some Scrum events). 


The Scrum master assists the development team by: 


™ coaching the development team in selforganisation—in the crafting of tasks to build the items on 
the product backlog into the sprint, and in coaching the cross-functions of the development team 
(see the following section on the development team’s role) 


@ helping the development team in the creation of highvalue products (output and outcomes) from 
the sprint 


m removing impediments (such as a lack of a particular skill, a lack of access to a tool, or 
interruptions to the development team by employees in the business) 


™ coaching the development team in respect to the Scrum framework, practices and values. 
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In order to do this, the Scrum master must be respected for their approach and should possess excellent 
people and communication skills. They are not a project manager, nor are they a team leader as the 
development team is selforganising (they allocate and report on the work at the daily Scrum event— 
often referred to as the daily sprint meeting). 

As the Scrum master is an overseer of the practices of Scrum, it is not uncommon for a Scrum 
master to oversee multiple Scrum projects simultaneously. An experienced Scrum master can typically 
oversee up to three development teams simultaneously. A very experienced Scrum master may be 
able to handle more than three development teams (although of course, they should exercise caution 
not to become overloaded). 


3.3.3 The development team 


The development team is a flexible team made up of the skills required to achieve the contents 
of the sprint backlog. On some occasions, this team may comprise design and solution-oriented 
team members (such as people skilled in business analysis and technical solution design). On other 
occasions, the skills required by the team may comprise development and testing. 

Characteristics of the development team include: 


The team is selforganising: not even the Scrum master will tell the development team how to 
turn the sprint backlog into increments of potentially shippable product (or potentially releasable 
production code); they must instead be coached with the skills to do this by the Scrum master 
(with input from the product owner). 


E As introduced above, the development team must have the correct skills (resources) to achieve 
the contents of the increment (sprint). No formal role titles are recognised by Scrum, instead, 
team members are all effectively ‘devs’. 


E There are no subteams and no hierarchy: the development team must instead work as one team 
to achieve the sprint goal jointly, and must support each other to do this. 


As emphasised, they are a truly empowered team whose focus must be on delivering the agreed sprint 
goal and content. This arrangement can be challenging for traditional environments where developers 
are used to operating under a team lead and being separate from other functional teams, such as 
testers and business analysts. 

The team’s size should therefore be such that this arrangement can be achieved. Usually a team 
size of 7 +/— 2 members can produce excellent results. Any smaller and the achievements may be 
limited; any larger and self-organisation and communication can become problematic. 

Typically, the team is co-located (in the same office space) to facilitate ease of communication, 
team cohesiveness and team rapport. (Referto Table 3.1 for a summary of Scrum team characteristics). 
If colocation is not possible and the team is a ‘virtual’ team, careful consideration will need to be 
given to the enabling technology that can provide some of the benefits of co-location (e.g. shared 
online spaces, video conferencing, intelligent whiteboards). 


WHO ARE THE ‘DEVS’ IN THE DEVELOPMENT TEAM? 


This is often a difficult concept to grasp in a Scrum environment. The development team will comprise 
all of the resources required to be able to fulfil the definition of ‘done’ for the sprint. Therefore, 
the skills required will vary from sprint to sprint. For example, one sprint may require a business 
analyst capability to refine story cards into requirements suitable for later coding and testing, while 
another sprint may require technical capability to establish environments and databases. Some 
sprints may require elements of all capabilities to deliver the definition of ‘done’ for that sprint. 
A ‘dev’ may have multiple skills and be able to clarify requirements, code and then test them. Hence, 
the development team could be multi-skilled, and/or individual team members could possess multiple 
skills as individuals. 
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SNAPSHOT FROM PRACTICE Trello and Scrum 





In a recent Scrum project, the Scrum team members were 
geographically dispersed. A software tool (Trello) was used 
to create a virtual version of the sprint board (Kanban board). 
As stories and tasks were being actively updated, they were 
moved across the board, from the ‘to-do’ stack to the ‘doing’ 
stack and so on. The key tracking screen of Trello was 
displayed on a large-screen TV in each location, so visual 
progress could easily be followed 24/7. This was combined 
with video-conferencing using the respective TVs, enabling 
the daily Scrum to take place with geographically dispersed 
members of the team being able to see the sprint board and 
see/hear each other during the daily Scrum event. 

For a greater understanding of the features of Trello, 
refer to https‘//trello.com. Note that there may be other 


Figure 3.3 Example of a Trello sprint board 


products more suited to your business environment, so 
always scan the market place for the most suitable tool. 

Two Trello screen shots appear in Figure 3.3. These 
screen shots were taken during the early stages of 
development of the second edition of this text. The first 
screen shot indicates the Trello board, with lists visible 
for work ‘To-Do’, ‘Doing’, ‘Proof check’, ‘With McGraw- 
Hill’ and ‘Done’. Within in each list appear a number 
of story cards, effectively the to-do list represents the 
product owners, product backlog. The second screen 
shot indicates some of the detail that can be populated 
behind each story card such as coloured labels (the blue 
represents chapters), assignment of team members, and 
a commentary of dialog. 
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Table 3.1 Scrum team characteristics 





Key attribute Characteristics 

Dedicated team Increases productivity by removing the need to multitask. 

aes Focuses on the sprint goal: a single agreed vision for the sprint. 

Co-location Physical co-location is preferred—consideration needs to be given to virtual teams. 


Co-located teams have superior team dynamics: teams communicate better (including sharing information and knowledge 
and recognising non-verbal cues) and have greater commitment to each other and to the team. 
Teams combining Bringing together specialist expertise and the flexibility of generalists calls for greater flexibility from team members 
specialist and (e.g. a business analyst skillset might be expected to participate in other levels of tests). 
STE Tae Pe mise Teams have the skills needed to achieve the sprint goal. 
The ideal from the authors’ experience is a team comprising between five and nine people. 
People are trained in the skills required to carry out all their respective tasks, whether generalist or specialist. 


Known work The development team and wider Scrum team agree on a work approach. 


environmen Teams build on artefacts already produced (they don't reinvent the wheel). 


Teams know that they depend on each other to deliver the outcomes and outputs of the sprint—no single person alone 
can achieve these goals. 


Teams share the work and take credit as a team for the successes produced. 


Note: A ‘Scrum team’ is the term used to denote all the Scrum roles collectively (the Scrum master, the product owner and the development 
team). 


IN THEORY The MoSCoW prioritisation technique 





MoSCoW is a simple method used to assist in the 
prioritisation of product backlog items. Each item is 
classified by the product owner (as the empowered 
decision-maker) as being one of the following: 


M is a Must-have item—it must be attended to by 
the development team. The word ‘MUST’ has further 


Cis a Could-have item—it is a feature that is desirable, 
but does not have to be attended in order to to 
support the implementation of the Must-have or 
Should-have at this point in time. 


W is a Won't-have item—it is not considered to be a 
priority at this time. 


importance because it is the Minimum Usable 
SubseT of items needed to produce a ‘done’ (or 
implementable) feature of the end-product. 


MoSCoW helps us to remember these four classifications. 
The product owner has to understand the value of each 
item on the product backlog list, and be able to classify 
each item accordingly. Remember that part of the Scrum 
master’s role is to support the product owner in being 
able to understand and apply such techniques. 


S is a Should-have item—it is important but is not 
imperative (i.e. is not a Must-have item). There could 
be a manual or other workaround in the business until 
this feature is accommodated in a future sprint. 


3.4 SCRUM EVENTS 


These are few in nature, but effective in use. They include: the sprint, the sprint planning meeting, the 
daily Scrum, the sprint review and the sprint retrospective. 


3.4.1 The sprint 


The sprint is a timebox of between one and four weeks, determined by the effort required in the sprint 
planning meeting. @rganisations usually move into a routine of using the same timebox (twoweek 
sprints are the most popular in practice). Estimating the work that can be done in this timebox may be 
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done accurately through the repeated use of the burndown chart, and in the understanding of velocity 
(discussed later in this chapter). At the end of the sprint, a set of ‘done’ work will be accomplished. 
This work is what we call ‘potentially shippable’ (e.g. it could be production-ready code). 

During the sprint: 


Æ Quality is at the forefront of the sprint approach. Quality must not be jeopardised by attempts to put 
more into a sprint to get more done, only to have to correct more defects later! Sometimes dev teams 
talk about done-done, which effectively affirms the work has been done according to the story card, 
and the story has been tested according to the acceptance criteria; therefore, it is donedone! 


= The sprint contents are not changed—this would endanger the sprint goal (the sprint goal is 
agreed at the sprint planning meeting and is encapsulated in what is to be achieved in the sprint. 
It is developed by the development team during the sprint planning meeting). 


Em The scope of the sprint can be changed only through negotiation between the product owner 
and the development team. Employees of the organisation are not allowed to approach the 
development team directly with changes to the sprint; they must work through the product owner. 


E The product owner can then bring these changes to the development team. 


Each sprint could be considered a ‘mini’ project, where the work is planned, designed, developed and 
potentially implemented. The product owner is the only person who can cancel a sprint before it is 
over. The cancellation of sprints rarely occurs in practice; timeboxes are of relatively short duration 
so work is usually allowed to be completed. A sprint may be cancelled if business circumstances have 
significantly changed, or the product's development has been suspended. 

Often sprint 0 is a ‘get-ready’ sprint that is used by the Scrum master and the development team to 
establish the environments, software tools, protocols and standards to be used across the entire Scrum 
project. As such, the sprint may be shorter in duration and may not directly produce any business 
related potentially shippable product. The sprint will still have a definition of ‘done’, will apply the Agile 
Manifesto, and, in itself will provide a test of confidence in the development team’s ability to work 
together as an empowered team under the ‘servant leadership’ arrangement with the Scrum master. 

The final sprint in an increment is often an integrativetype sprint where the potentially shippable 
products from previous sprints are integrated and actually ‘shipped’ or implemented in the business. 


3.4.2 Sprint planning 

Sprint planning takes place at the start of each and every sprint. The work will be estimated using 
the popular story point technique (see In Theory: Planning Poker) and a definition of ‘done’ will be 
crafted for the entire sprint, which will become the focus for the development team. Sprint planning 
is put into the hands of the development team. They, with input from the product owner, will decide 
which product backlog items are to form the content for the sprint. The sprint planning meeting is 
usually split into two stages and is split 40/60 in terms of time, between: 


™ agreeing on what can be achieved in the sprint (i.e. deciding which product backlog items are to 
go into the sprint backlog with input from the product owner), and 


@ deciding how the chosen sprint backlog items are going to get done by the development team. 
This usually results in a story on its ‘story card’ being broken down into a number of tasks, 
which the development team must accomplish. These tasks could be tasks that ultimately end-up 
being allocated to different devs in the development team once the sprint commences. Further 
explanation of the story card is provided in section 3.6 Scrum artefacts. 


The sprint goal will be established at the sprint planning meeting. This is the development team’s 
understanding and agreement of the ‘what’ and ‘why’ it is building: the increment of ‘potentially 
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shippable product’. The sprint goal becomes the focus for the sprint and could be printed out as a 
banner in the development team’s workplace. 


3.4.3 The daily Scrum 


The daily Scrum, a short 15-minute timeboxed event, is where the development team synchronises 
activities and plans the next 24 hours. Referencing the visual story board (from where the sprint 
backlog stories are managed), the development team (in a self-organising manner) gathers around the 
board and each discusses the following three key items: 


1. What they have achieved in the previous 24 hours towards their allocated stories and associated 
tasks. 


2. What they are planning to do today (i.e. in the next 24 hours) to help the development team meet 
the sprint goal. 

3. What impediments they envisage are in the way of them achieving the story, tasks or sprint goal 
and how they plan to overcome these and what assistance they may need from, for example, the 
Scrum master or product owner. 


Each member of the development team must speak and will have only about two minutes to do so. 
They must therefore come fully prepared for the daily Scrum. 

Remember that although the Scrum master makes sure this meeting occurs, they are not a 
team lead for the meeting—instead, the development team must collectively act as an empowered 
team as no team lead role exists in Scrum. The Scrum master may take away information about 
some of the impediments and action them; for example, if a business representative is approaching 
the development team directly, it is the Scrum master who will take this impediment away by 
working with the business representative to explain how Scrum works and to educate them about 
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the impact their interruptions are having on the development team (this promotes elements of 
servant leadership). 

At the end of each 24hour period the Scrum master would also request that the development team 
update the completion (in terms of story points) made against their selected stories and tasks. The 
Scrum master would use this information to track progress in the burndown or burnup chart discussed 
in section 3.6 Scrum artefacts. 


3.4.4 Sprint review 


At the end of the sprint, the increment is reviewed and (hopefully!) is accepted by the business. The 
product owner also outlines the stories that have been ‘achieved’, ‘partially achieved’ and ‘not achieved’ 
to the invited stakeholders. Note that these will be later updated back into the product backlog so the 
product owner can reassess/review the product backlog and reprioritise, as required, in readiness for 
the next sprint planning meeting. 

Aspects considered at the sprint review include: 


E the audience—including the product owner and other key stakeholders, as determined by the 
product owner 


@ ademonstration of what has been ‘done’, to gain acceptance by the business of what has been 
‘done’ and to answer any questions. This could result in further product backlog items being 
raised by stakeholders attending the review, which would then be represented back on to the 
product backlog as ‘new stories’. This often happens when an increment is released, but the 
business now sees a way of enhancing this feature to extract further value from it 


E any problems encountered by the development team (when working with the business) and how 
any such problems were resolved 


E areview by the product owner of any changes to the business environment and inputting these 
into the ‘what to do next’ discussion 


E ageneral review of the increment, the sprint, the resources utilised, and the budget for the next 
increment. 


3.4.5 Sprint retrospective 


A sprint retrospective is a shorter meeting that takes place after the sprint review meeting. The 
sprint retrospective covers the traditional questions of: 


@ What went well? 

m What didn’t go so well? 

@ What could have been done better? 

The Scrum master participates in this meeting as a peer member of the development team. It is an 


opportunity to reflect on the Scrum framework and make changes to it. Items could be raised on any 
matter, but often includes discussions about: 


@ working with the business—people, relationships and politics 


E applying the Scrum framework—where this went well, but also where improvements can be made 
and who will action the improvement (preferably before the next sprint) 


E outstanding impediments that need to be actioned 


Æ considerations around product quality and how well this is being achieved, the definition of ‘done’ 
and the sprint goal 
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Em environmental considerations—not only in terms of the physical environment, but also in 
terms of the tools used (whiteboards or virtual sprint boards) through to team reward(s) and 
acknowledgement of achievements. 


As the Scrum Guide indicates, a Scrum retrospective is an opportunity for the whole Scrum team to be 
able to inspect and adapt (known in some circles as ‘action learning’). 
For the time allocated to the various Scrum events refer to Table 3.2. 


Table 3.2 Scrum event timings 


SS] 2-week sprint 4-week sprint 


Sprint planning meeting 4 hours (timeboxed), split 40/60 between: 8 hours (timeboxed), split 40/60 between: 
m Whatcan be done in this sprint? m What can be done in this sprint? 
m How will the chosen work get done? m How will the chosen work get done? 


15 minutes (timeboxed), start of each day 15 minutes (timeboxed), start of each day 
2 hours (timeboxed) 4 hours (timeboxed) 
1.5 hours (timeboxed) 3 hours (timeboxed) 


Daily Scrum 
Sprint review 
Sprint retrospective 


IN THEORY Planning Poker® 





Planning Poker is an Agile technique used to estimate 
(and later track) the amount of work effort in story points 
for each story (or item) on the product backlog, ‘Points’ are 
an arbitrary unit of measure for expressing an estimate of 
the overall effort that will be required to fully implement a 
product backlog item. Some development teams use half 
day increments, or hours. However, when this story point 
principle is adopted and the development team becomes 
comfortable with ‘effort-to-story-points’, the process of 
estimating becomes more accurate. This is because the 
development team İs focuseel on discussing the relative 
complexity of each item on the product backlog rather 
than on ‘time’. For example, this could be expressed as 
product backlog item A being 13 times more complex 
than product backlog item B. 

As seen in Figure 3.5, the development team typically 
uses a set of Planning Poker cards. The standard number 
sequence is normally based on the Fibonacci sequence, 
with additional cards used for higher story points. For 
example, a question mark (2) for ‘| don’t understand’, 
and the infinity symbol (co) for a number greater than the 
largest number in the deck of cards being used (i.e. too 
large to estimate). 

The development team sits around a table with the 
product owner ane describes the first item (story) on 
the product backlog being considered. (Remember: 
The product owner would have assessed the value of 
each product backlog item, and prioritised this using the 
MoSCoW technique.) 

The development team next votes on the points they 
see the story as being worth by each simultaneously 
placing (face-up) in the centre of the table an individual 


Figure 3.5 Planning Peker in actien 
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Source: 





card from their personal set of cards, so that its value can 
be seen. Examples of the differing scenarios that could 
arise from Planning Poker (involving a story point value, a 
question mark or the infinity symbol) include: 


m Ifthe presented card values are the same (for the story 
point), then the product backlog item would be added 
to the sprint backlog and the development team 
would progress onto the next prioritised item from the 
product backlog list. 


m Ifthe presented card values are vastly different, a 
discussion would take place (the story could even 
be broken down into more granular stories and 


(Continued) 
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IN THEORY Planning Poker (Continued) 





re-estimated), 
across the development team and can be 


re-estimated. 


so the story is better understood How do you know when to stop adding 
stories to the sprint backlog? 
This typically lies in tracking progress from previous 


m If devs have put down a care @isplaying a question sprints (termed sprint velocity). The Scrum master will 
mark, the proeluct owner ades clarification, ane then be in a position to avise on how many story points are 


the story is re- 


estimated. being achieved across sprints (of the same nature). This 
will inform the maximum number of story points that can 


m |f devs put down an infinity symbol card, the story be achieved in the sprint. (Refer to later sections in this 
would be broken down into more discrete stories chapter on how to calculate sprint velocity.) 
with input from the product owner given that the devs A helpful resource for this process, in the form of 
have inglicate@ that the story is too large for them to a Planning Poker app, can be foune at: https://www. 
estimate in its current form. mountaingoatsoftware .com/tools/planning-poker 


3.5 EPICS, INCREMENTS AND SPRINTS 


Before the Scrum artefacts are outlined, further details on the terms epic, increment, sprint and 
product backlog are discussed together with an explanation of how these terms form the structure 
of the work within a Scrum project. Figure 3.6 indicates how these terms are often used to plan the 
delivery of work in a Scrum project. 

The Scrum master, product owner and development team will have input into the creation of 
such a structure as per the Scrum events previously described. However, as with all things Scrum, 
structures are subject to change as reviews (formerly called ‘grooming’) are carried out during the 
sprint planning and review meetings and by the product owner managing the product backlog. 

Figure 3.6 illustrates the structure of work for a Scrum project. It has been separated into two 
epics: a sizable release of product. Within the first epic, two increments have been defined: 


m Increment #1 has three sprints (0, 1 and 2). 


Æ Sprint 0 is to deliver product backlog items #1, #2, #7 and #9. 


Sprint 1 and 2 would deliver an agreed set of product backlog items (agreed at the sprint planning 
meeting). Increment 2 has two sprints (3 and 4) and would deliver a selected number of product 
backlog items. The second epic has only one increment, to be delivered by a number of sprints yet to 
be confirmed. 

So where do tasks come into this structure? Recall that tasks were a result of the development 
team having planned the detailed tasks (activities) required to deliver a ‘done’ product backlog item 
(story card). In Figure 3.7 this is illustrated for product backlog item #1. Note that the development 
team will require four tasks to be completed to accomplish it. 

The structure of a Scrum project could actually be very simple. It could, for example, exclude epics 
or even multiple increments and just have a single increment delivered through a small number of 
sprints. Size, complexity, risk and control factors would all come into play (as input from the product 
owner) when the structure of a Scrum project is designed. 

Increments, individual sprints, or even product backlog items, must have a shared understanding of 
the ‘definition of done’. This ‘definition of done’ would be developed, for example, at the increment or 
sprint outset, and creates focus on what is to be achieved across all members of the Scrum team (product 
owner, development team and Scrum master). The ‘definition of done’ could be represented as a list of 
criteria which must be met before an increment, sprint or product backlog item is considered as ‘done’. 
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3.6 SCRUM ARTEFACTS 


A number of Scrum artefacts have been mentioned in this chapter so far, and the following section 
provides further details with examples. The artefacts considered include the product backlog, the 
sprint backlog, bumdown/burnup charts, and the finished work (often referred to as the ‘potentially 
shippable product’). 


3.6.1 Product backlog 


The product backlog is a changeable list of the business requirements (also known as ‘product backlog 
items’, or sometimes ‘stories’, ‘features’ or ‘requirements’) for the product being built, as determined by 
the business. The list is ordered according to the value the business sees from the requirement being 
implemented in the business. It is therefore owned by the business (in particular, the product owner). 
The product owner is the accountable, empowered owner of the list: they liaise with the business and 
user groups in the business and provide a single entity (ie. a single person, not a group of people) for 
the development team to liaise with in relation to the items and the priorities set. The product owner 
has the final say as to the contents of the product backlog, and therefore must be respected and 
empowered to represent the business. There are many techniques which the product owner could use 
with the business in order to extract high-level requirements; for example, the ‘Brown Cow’ technique. 
As illustrated in Figure 3.8 the grid aims to differentiate between what the business wants to do from 
how it wants to do it, across the time dimensions of ‘now’ and ‘in the future’. 

This technique could also be used at other points in the Scrum proceedings, such as in the sprint 
event itself by members of the development team, in extrapolating and clarifying requirements. 

The product backlog could be a manually maintained set of story cards pinned to a visual 
storyboard wall or they could be virtual equivalents in a software tool such as a Trello or, for more 
complex tracking, tools such as Jira could be used. The more complex tools allow customisation to 
include estimating and prioritisation information that can be later reported on for sprint monitoring 
purposes in the form of burndown and/or burnup charts. 

Whichever medium is used, the accepted format for a story is: 


As a < type ef user >, I want < seme geal > se that < seme reasen >. 


Figure 3.8 Brown C 
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Examples: 


E Asa < website visitor > I want < to be able to reset my password > so that < I can still access my 
account even if I forget my password >. 


E Asan «< end user >I want < to securely enter card details > so that < I can store credit. card details 
for future transactions>. 


A useful checklist to refer to when writing story cards is the INVEST acronym (Independent, 
Negotiable, Valuable, Estimable, Small and Testable; refer to In Theory: The INVEST Acronym). This 
technique could be used by the Scrum master when coaching the product owner to write better quality 
story cards for the development team (potentially helping to avert several questions and issues in 
estimating the story during the sprint planning meeting). 

Many sites provide examples of product backlogs. Mountain Goat Software describes the initial 
functionality for the Scrum Alliance website at https:/Wwww.mountaingoatsoftware.com/agile/scrum/ 
scrum-tools/product-backlog/example. 

As the Scrum project progresses and a number of sprints have been ‘done’, the items on the product 
backlog could expand to include story cards beyond pure business requirements. Stories are often 
classified into the following categories: 


E Feature (item/story/requirement)—the source of most of these is the product owner (representing 
the business), supplemented by additional stories raised by the development team. 


m Bug (defect)—potentially raised by anyone, at any time, but more frequently raised as a result of 
applying testing (acceptance criteria: the back of the story card). 


E Technical work—work that needs to be accomplished to put down technical foundations, such 
as creation and configuration of databases, installation of hardware, or software installation and 
configuration. 


E Knowledge acquisition (research, or sometimes referred to as ‘spikes’)—activities from training 
to research. This is accounted for in a sprint as a story card because effort will be exerted in 
carrying out the activity. 


If the Scrum team is using manual story cards and the storyboard wall technique, differentcoloured 
story cards can be used to represent each of these types of items on the storyboard. This renders it. 
easier to be able to identify the product backlog, and ultimately to facilitate what gets carried forward 
and is worked on by the development team in the sprint backlog (after the sprint planning meeting: 
refer to Figure 3.9). 

The story card (or its equivalent) is based on a concept that Ron Jeffries 
documented in 2001 as part of his approach to XP (eXtreme Programming). He 
proposed to distinguish ‘social’ user stories from ‘documentary’ requirement practices 
such as use cases, and so the story card emerged and along with it the acronym, ‘The Figure 3.9 Coloured story cards 
3Cs’. In his ‘Card, Conversation, Confirmation’ model, Jeffries (2001) defines: 





E a ‘Card’ (or often a PostIt? note) as a physical token giving tangible and 
durable form to what would otherwise only be an abstraction 


E a ‘Conversation’ as taking place at different times and places during a project 
between the various people concerned by a given feature of a software 
product: customers, users, developers, testers. This conversation is largely 
verbal but is usually supplemented by documentation 


E a ‘Confirmation’ as occurring once the objectives the conversation revolved 
around have been reached (Jeffries 2001). 


Source: @ 2018 Dr Neil Pearsen 


So, where does the ‘Confirmation’ get documented? On the reverse of the story card. 
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Refer Figure 3.10 for an example of a completed (front and back sides) story card. Note that 
confirmation criteria in Scrum are more commonly called ‘acceptance criteria’ and appear on the 
reverse of the card. 

As described, the product backlog might be maintained in a manual storyboard format. However, 
with anything but the simplest of projects, this can become an arduous task. Many practitioners 
therefore use spreadsheets or software tools to assist with defining and managing the items on the 
product backlog. Refer to Figure 3.11 for an example of a segment of a product backlog, captured ina 
spreadsheet format and a popular software tool—Jira. 

These story cards are an important concept for capturing the business requirements, and as such 
might be referred to as ‘functional requirements’ in a traditional business analyst context. 

The stories could be likened to a business analyst capturing the ‘system use case’ diagram and 
the individual ‘user cases’ captured within the system use case diagram. This necessitates a more 


advanced discussion with your development team members. Be warned, however, that there are 


Figure 3.10 ple story card 





Story card (front) Story card (back) 





| As a < student >, i want 





| <to purchase a car park pass > 





3) Must be a cu 











4). Must have a valid driving license. 























Source: @ 2018 Dr Neil Pearson 
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Figure 3.11 As 


eadsheet and software to maintain product backlog 


website visitor be able to reset 


my password 


I can still access my account 
even if | forget my password 


<As a / an> website visitor <| want to > be able to reset 
my password <so that> I can still access my account 
even if | forget my password 


website visitor be able to recover 


my username 


1 can access my account if I 
have forgotten my username 


<As a / an> website visitor <| want to > be able to 
recover my username <so that> | can access my 
account if | have forgotten my username 


authenticated 
website visitor 


see a customised 
homepage 


Lam more engaged with the 
website 


<As a / an> authenticated website visitor <I want to> 
see a customised homepage <so that>! am more 
engaged with the website 


website visitor view a home page | | can see the most important 
content at a glance and 
quickly understand the site 


navigation 


<As a/ an> website visitor <| want to > viewa home 
page <so that> I can see the most important content at 
a glance and quickly understand the site navigation 


website visitor be able to log in to] I can see tailored content and 
the site manage my relationship with 


the company 


<As a / an> website visitor <| want to > be able to log in 
to the site <so that> I can see tailored content and 
Manage my relationship with the company 


website visitor be able to register 


for an account 


I can login and gain all the 
benefits of being an 
authenticated user 


<As a / an> website visitor <| want to > be able to 
register for an account <so that> | can login and gain all 
the benefits of being én authenticated user 
authenticated 
website visitor 


be able to manage] I can update incorrect or 
my profile details changed details and view 
current records 


<As a / an> authenticated website visitor <I want to> 
be able to manage my profile details <so that> | can 
update incorrect or changed details and view current 
records 

authenticated 
website visitor 


be able to log out 
of the website 


my private information is kept 
secure when accessing the 
site on a shared computer 


<As a / an> authenticated website visitor <I want to> 

be able to log out of the website <so that> my private 
information is kept secure when accessing the site ona 
shared computer 











Source: @ 2018 Dr Neil Pearson 
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Figure 3.12 





Be able to reset my 


password Student profil 
Be able to recover Resét 
my username password 


See a customised 

homepage 
Recover 
username 


Customise 
homepage 


Student 





often differences in the level of abstraction of user cases. Some system use case diagrams will 
indicate quite high-level requirements, or will require further detail when pushed into the sprint 
planning meeting. 

Figure 3.12 shows a partial system use case diagram for three items as indicated in the product 
backlog list (refer to Figure 3.11). A ‘Student’ to ‘Reset Password’ would be referred to as a user case, 
and could be an individual story card. The same would apply for the ‘Student’ to ‘Recover Username’. 

Discussion on the elicitation of business requirements would take place with the development team 
at the outset of the project, so that a consistent approach is taken. 


3.6.2 Sprint backlog 


The sprint backlog is, in essence, a subset of product backlog items that have been accepted for 
development by the development team (refer to the above section on sprint planning) into the current 
sprint. However, note that the sprint backlog will contain additional information (data) as defined by 
the development team and Scrum master. For example: 


E The Scrum master might require that the development team record progress made towards 
completion of the story at the end of each day. This information would be recorded in the selected 
medium/tool, after which the Scrum master would be able to see the burndown or burnup charts, 
indicating progress referred to as ‘monitoring sprint progress’ (refer to the later section in this 
chapter for details on the burndown, velocity and burnup techniques). 


m The development team may wish to break a story down into its requisite tasks which they need to 
individually complete in order for the story to be completed or ‘done’. 


m The development team (froma business analysis perspective) might then have information 
recorded against each task, in relation to the stakeholder who was consulted, a record of 
discussion etc. 


=m The development team (froma tester’s perspective) might want to record further details about the 
quality/testing of an acceptance criteria. 


Tip: This is where, from a practical perspective, applying Scrum (in the business) and the Agile 
Manifesto collide. The Scrum team have to agree on the extent of documentation required, as the Agile 
Manifesto states, ‘Working software over comprehensive documentation’. 
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Figure 3.13 represents an example of a development team sprint story board (sometimes referred 
to asa Kanban board) in action. 


3.6.3 Final product 


The output of every increment and/or sprint is called a potentially shippable product. This is a key 
concept in the way Scrum operates. A sprint should be planned so it will deliver a potentially shippable 
product increment. ‘Potentially shippable’ means that the product (whether software or other) could 
be put into a production environment and released to its end-users. This concept would be reinforced 
by the Scrum master at the sprint planning meeting and in interactions with the product owner when 
reviewing and maintaining the product backlog items on the product backlog. 


3.6.4 Burndown, velocity and burnup techniques 


Sprint progress monitoring is carried out using burndown and burnup charts. These charts are flip- 
sides of the same coin: the burndown chart shows how much effort (in story points if this is how the 
product backlog item was estimated) is remaining (i.e. not done), while the burnup chart shows the 
opposite-how much work is left to be done. 

A burndown chart is constructed by putting the story point scale on the vertical axis (i.e. the scope 
of the increment or sprint to be achieved usually in story points) and the time along the horizontal axis 
(10 working days for a two-week sprint). This can be seen in Figure 3.14, where a burndown chart is 
plotted over a two-week sprint. 
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7234686728910 


Story point 





72348678910 














723468678910 


Today 





723468678510 
D; 


Source: © 2018 Dr Neil Pearsen 


Day 0: The starting point, indicating the total number of story points 
estimated for the sprint during the sprint planning meeting. 


Day 1: The development team have updated their tasks with work 
completed in story points. The Scrum master runs the burneown chart 
report. The Scrum master is pleased with Day 1! 


Day 5 (the end of the first week of the two-week sprint): The development 
team updates their tasks before leaving for a well-earned weekend break. 
The Scrum master reviews the burndown chart ane sees that steady 
progress has been made and the number of story points remaining. 

Work is on track at the halfway point through this 2-week sprint. 


Day 6: The Scrum master notices an increase in the scope or story points. 
What happenee? The product owner and development team increased the 
scope of the sprint ane this was then reflected in the burndown chart. The 
Scrum master investigates the circumstances and discovers that a story was 
misinterpreted by the development team ane a small amount of effort was 
added to the sprint. The Scrum master ane product owner now need to 
consider whether the work planned for the sprint is achievable. It is decided 
that an en@-ofday 7 status check will be required, to assess the 
development team’s progress towards achieving the end date (Day 10). 


Day 7: Good news—it appears the development team has made some 
good progress (without staying late). The Scrum master and product 
owner are happy to monitor the status, as per normal 


Day 10: The final burndown chart is reviewed and, due to the previous 
increase in effort. the sprint didn't quite achieve a 100% burn@own. At the 
sprint review meeting, the work remaining was place@ back into the 
product backlog for review ane re-prioritisation by the product owner. 

At the sprint retrospective lessons review, the increase in work was 
reflected upon and the process of writing stories was refined with further 
coaching of the product owner by the Scrum master. 
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A burnup chart shows the opposite information: the work completed bumingup towards the 
amount of scope (story points) estimated at the sprint planning meeting. In Figure 3.15, the burnup 
chart shows a two-week sprint on Day 9. The sprint has made good progress and looks set to complete 
the estimated story points at the end of the timebox: Day 1@. 

Burndown and/or burnup charts should be plotted for the purpose of monitoring progress. The 
Scrum master can use these charts to raise questions about progress and about impediments to pursue 
the objective of achieving the increment/sprint goal within the timebox (sprint length). 


3.6.5 Sprint velocity 


Another useful metric to track is the sprint velocity. This is simply the number of story points 
achieved at the end of the sprint. If this metric is tracked over a number of sprints, it can help to inform 
(sometimes very accurately, if the sprints are of the same nature) the amount. of work that can go into 
a sprint during sprint planning. 

Figure 3.16 shows the average sprint velocity across an increment consisting of three sprints. 
The resulting sprint velocity number would be used to inform the number of story points that can be 
included in a sprint in future sprint planning meetings. 

Snapshot from Practice: Suncorp’s adoption of Agile methods illustrates the use of Agile at Suncorp 
Bank, Australia. The reader should now be familiar with the terminology used. 


SNAPSHOT FROM PRACTICE Suncorp’s adoption of Agile methods 





Suncorp is a banking and insurance company that has 
its headquarters in Brisbane, Australia. The company 
employs in excess of 16000 people, and has over 
7 million customers and an A$8 billion asset base. 
Suncorp started its transition across the company to 
the Agile approach to project management in 2007 with 
the arrival of a new Chief Information Officer, Jeff Smith. 


With over 4000 people employed in the ICT department 
alone, Agile became ‘the way we work around here’ 
where previously a heavyweight ‘waterfall’ approach 
had been used. In support of its Agile implementation, 
Suncorp invested in: 


(Continued) 
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SNAPSHOT FROM PRACTICE Suncorp’s adoption of Agile methods (Continued) 





m an Agile change program, to change-manage the m facilitating the incremental testing of changes 


introduction of Agile into and across the business : 
m more efficient use of resources—streams can 


m an Agile education program to develop the skills operate in parallel (Presence of IT n.d). 
required (enabled via The Agile Academy, an external 
training organisation specialising in the Agile approach 
to project management) 


The team utilised key aspects of Agile during 
implementation, including: 


m incorporating the customer as part of the Agile 


m coaching and mentoring programs to build on existing product team 


skills and to leverage benefits from experienced 
practitioners (Couzens 2009). m including the business subject matter expert (SME) 

as part of the team, ensuring that any changing 
requirements were met in a timely and practical fashion. 
The SME was able to influence what features were 
added, changed or removed based on priority and 
value. The SME gained insight into project complexities 
and was able to inform business decisions 


An example of the Agile approach being applied within 
Suncorp appears in Case Study: Standardised Enterprise 
Bargaining Agreements (Presence of IT n.d). The project 
was to standardise Enterprise Bargaining Agreements 
(EBA) using Agile and set out to merge eight into a single 
agreement, subsequently translating the single agreement 
into the PeopleSoft Human Capital Management (v9) æ writing requirements as acceptance tests before 
system. Some of the recognised benefits of taking an coding commenced 


Ensue ap pie AEMT EOE values m ensuring acceptance criteria were agreed with the 


m flexibility—reducing the risk of delays caused by SME, and a representative of each team role, at 
changes in business requirements the time of elaboration. This ensured that business, 
development, testing, processing and communication 
perspectives were raised and addressed to find the 

best-fit solution 


m management of ‘unknowns’—components with 
uncertain requirements can be developed last to allow 
maximum time for clarification 

m automated testing where possible 


m writing independent testing and verification scripts 
alongside the code-line development to support 
traditional testing methods. This was critical in 
building a repeatable suite that could be utilised for 
the iterative nature of the Agile methodology 


m negotiating schedules rather than assigning them 


m iteration planning to give the business a chance to 
determine the work to be completed in the next 
iteration and allowed for course correction. The 
entire team participated in the sessions, and was 
encouraged to identify risks, dependencies and 
bottlenecks. The team then committed to the work 
identified (Presence of IT n.d.). 


The great success of Agile within Suncorp is evident 
not only from a customer's perspective in the innovative 
products and services that have been broughtto market, 
but also in the many positive press articles reported in 
trade and professional magazines across Australia. 


Source: Couzens JA 2009, ‘implementing an enterprise system at Suncorp 
using Agile development’, www agileacademy.com.au/agile/sites/@default/ 
files/ASWEC2009-InglustryPaperJamesCouzens pef, accessed December 
2012; Presence of IT n.d., ‘Suncorp standardized EB agreements using 
Source: @ 2018 Dr Neil Pearson Agile’, www.presenceofit.com.au/casestudies/suncorp-standardised-eb- 
agreements-using-agile, accessed December 2012. 
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3.7 SCRUM (AGILE), PRINCE2 AND PMBOK 


Although the ultimate would be to adopt Scrum in its purest form—t o really drive value from the 
adaptiveness of the framework, in reality this is often not practical. It is for this reason that we often 
see the terms TAgile and WAgile bandied about. TAgile is the combination of traditional project 
management and Agile used together from a project management perspective. WAgile is often used 
from a development perspective, blending the waterfall method of software development with 
Agile techniques. As this text does not cover the ‘development’ realm, we will focus on the project 
management phrase: TAgile. 

Enhancements have occurred in recent years to both PRINCE2 and the PMI's Guide to the Project 
Management Body of Knowledge (also known as PMBOK) (PMI 2017a), which cover the use of Agile 
within their respective approaches. Hence, the term TAgile has emerged. 

The following sections consider how the PMBOK and PRINCE2 each consider Agile within their 
respective Predictive frameworks, where the majority of ‘up-front’ planning is carried out. 

Generally, for projects with: 


E alow degree of change and an infrequent delivery, we would adopt Predictive approaches 

E alow degree of change and frequent delivery, we would adopt Incremental approaches 

E ahigh degree of change and an infrequent delivery, we would adopt Iterative approaches 

E ahigh degree of change and frequent delivery, we would adopt an Agile approach. 

Refer back to Chapter 2 for definitions of Predictive, Incremental, Iterative and Agile approaches. 


Figure 3.18 indicates which life cycle approach is more commonly applied with ‘frequency of 
delivery’ appearing on the vertical axis, and ‘degree of change’ on the horizontal axis. 


3.7.1 PMBOK and Agile 


PMI took a hybrid approach (or what has been referred to as a TAgile approach—a combination of 
traditional, or Predictive, and Agile) towards the combining of Predictive and Agile techniques within 
the same project life cycle. The combinations are discussed by the Agile Practice Guide (PMI 2017b) 
and the latest edition of PMBOK (PMI 2017a). 

These combinations are described below: 


1. Indicates a hybrid approach where Agile development takes place, followed by a Predictive 
rollout. 


Figure 318 The life cycle continuum 






Although presented 
as a scale, it is in fact a 


continuum. 
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2. Indicates the use of both Agile and Predictive approaches being used at the same time. This 
is indicative of an organisation that is moving towards Agile but is hanging on to some 
Predictive practices. Perhaps the project is making use of daily Scrum events, product 
backlogs and other techniques, but is still using more traditional task assignment to achieve 
the work. 


3. Here, the predominant life cycle is Predictive. However, where uncertainty and complexity exists 
(and probably where there is more risk of scope creep), the project is using an Agile approach. 
Refer to Snapshot from Practice: Queensland Tertiary Admissions Centre—a hybrid approach, for 
an example of this predominately Predictive hybrid approach. 


4. This time the predominant life cycle is Agile, but where a component is non-negotiable or ring- 
fenced in some manner, a more Predictive approach is entered into. This could, for example, 
be an engagement with a vendor that uses Predictive practices or a set of mandatory business 
requirements that have to be developed verbatim in a predetermined sequence. 


In all cases above, the Predictive life cycle implied would be the PMI’s project management life cycle, 
as indicated in Figure 3.19. 


Figure 319 Project management life 





r ie 


Feasibility Assessment, Business Case and 


Pre-project 
Benefits Management Plan 


Initiation Project Charter and project establishment 
Planning Detailed planning for the project or stage 
Execution Execution of the project management plan 
Closure Closure of the project or stage 


Post-project 


Continued benefits delivery and assessment 


SNAPSHOT FROM PRACTICE Queensland Tertiary Admissions Centre—a 


hybrid approach 





The Queensland Tertiary Admissions Centre (QTAC) 
operates a centralised tertiary application service for: 


m publicly funded Queensland universities 
m Bond University’s medical program 
m TAFE Queensland 


m the Australian Maritime College 


m some courses at publicly funded universities in 
Northern New South Wales 


m some private tertiary education providers. 


Over the past three years, QTAC has investee in the 
replacement of legacy systems ane has invested in a 
program of redevelopment and enhancement to meet the 
demands of a changing business environment. A program 


was established using a largely traditional approach, 
initiated by the development of a comprehensive feasibility 
analysis and business case. 

The approach involved initially taking a traditional 
project management approach. After initial requirement 
elicitation had produced a detailed understanding of 
the ‘as-is’ processes, the development activity for the 
redevelopment of the legacy systems supporting these 
processes and updates to the process and other new 
enhancements to the systems, was moved into a more 
Agile manner of working. 

Development teams were formed to take subsets 
(the sprint backlog) of the prioritised list of ‘to-be’ 
requirements (the product backlog) to build increments 
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sub-set of stories in the sprint, this determined the mix 
of resources employed in each development team. The 
development teams typically comprised multi-skilled 
workers who were capable of refining requirements, 
coding, testing and implementing the product. 

Modules of shippable product were implemented 
once understanding and momentum in the business had 
been gained using an Agile approach. These shippable 
products ranged in scope from complete modules 
(replacing elements of legacy systems) and enhancements 
to processes (and systems) through to modules enabling 
new functionality to end-users of QTAC’s systems—a 
truly successful implementation of traditional and Agile 
approaches working together. 


of potentially shippable product. Depending on the 


3.7.2 PRINCE2 Agile 


PRINCE2 is a popular, globally expanding, structured project management method. Since its release 
in 2015, the Agile version of PRINCE2 has gained a significant following. PRINCE2 and Agile are both 
seen as having strengths as individual approaches to project management. However, contemporary 
thinking recognises that the two approaches complement each other and can be utilised to create a 
holistic approach towards managing projects, in an agile way. 

The strength of PRINCE2 particularly lies in the areas of project direction and project management. 
However, it is generally now viewed as having little focus on the field of product delivery. Conversely, 
Agile has a strong focus on product delivery, but relatively little focus on project direction and project 
management. When used in tandem, and therefore in a more holistic, TAgile way, the strengths of 
each can be drawn upon, at the relative stages of a project. As illustrated in Figure 3.20, PRINCE2’s 
‘directing’ and ‘managing’ aspects are largely retained, with the inclusion of Agile (sprints) for the 
‘delivery’ aspects of the project. 


3.7.3 Agile/Scrum software tools 


As indicated in Figure 3.13, ‘visual management’ is a key concept of Agile (Scrum) that has been 
adopted from lean management concepts. It is sometimes referred to as a Kanban board. However, as 
discussed earlier in this chapter, when the Scrum team is geographically dispersed or there are many 
dozens of product backlog items to manage, using manual techniques such as physical story cards 
may not be possible. Therefore, the use of software tools to assist the product owner in maintenance 
of the product backlog, and the development team in the breakdown of stories on the sprint backlog, 
may be required. 

At the time of writing, there are dozens of software tools in circulation that can facilitate these 
processes. They are (for the most part) fundamentally different tools to those used by a traditional 
project manager—y o u will, of course carry out your own research into such tools. 

Table 3.3 highlights some of the Scrum/Agile-based tools that have successfully been used by the 
authors in past and current Agile/Scrum projects. 

If no such corporate software tool is already in use in the organisation, then one of the first stories 
in Sprint 0 could be the investigation, selection and configuration of an appropriate software tool to 
assist in planning, monitoring and reporting product backlog items and capture information against 
each item so they may be managed as they move into the sprint. 
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Figure 3.20 PR 
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Table 3.3 Agile/Scrum toels 


Tool Link 


Jira (Atlassian software) https://www.atlassian.com/software/jira 

Trello (Atlassian software) https://www.atlassian.com/software/trello 

Pivotaltracker https://www.pivotaltracker.com 

Scrumwise https://www.scrumwise.com/features.html 

AgileScout https://agilescout.com/tool-review-agile-bench-easy-agile-projectmanagement/ 


3.8 LARGE-SCALE SCRUM (LeSS) 


Ken Schwaber and Jeff Sutherland generally discuss Scrum as being an empirical-process-control 
development framework, in which a cross-functional self-managing development team develops a 
product in an iterative incremental manner. Each sprint produces a potentially shippable product 
increment is delivered (and preferably implemented). 

Figure 3.6 indicated that Sprint @ would be progressed through the sprint framework, before Sprint 1 
would be started. Sprint 1 would then be progressed through, before Sprint 2 and so on (i.e. the sprints are 
carried out in sequence). However, there are many occasions, on large Scrum projects, where multiple 
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sprints will be carried out in parallel, and where there will be multiple product owners involved. To cater 
for the need for scalability in Scrum, the LeSS (Large-Scale Scrum) framework was developed. 
LeSS is described as being: 


a scaled up version of one-team Scrum, and it maintains many of the practices and ideas of 
one-team Scrum. InLeSS, you will find: 


m asingle Product Backlog (because it’s for a product, not a team), 

m one Definition of Done for all teams, 

m one Potentially Shippable Product Increment at the end of each Sprint, 

m one Product Owner, 

m many complete, cross-functional teams (with no single-specialist teams), 
m one Sprint (LeSS.works 2018 ). 


LeSS is truly scalable being suitable for up to eight teams (of eight. people each) while the ‘LeSS Huge’ 
framework can operate for up to a few thousand people on one product. 

Figure 3.21 provides a visual diagram of an increment (under a single accountable product owner) 
being developed though three parallel sprints. Additional complexity for the Scrum master comes 
in the form of interactions across the sprints, which must now be managed. Given the essence of 
Scrum, it is not necessary for the Scrum master to ensure integration takes place, but to empower the 
development teams to integrate the components and communicate across the three parallel sprints 
with different development teams. The Scrum master will of course assist in removing any relevant 
impediments raised (e.g. at the daily Scrum). The Scrum master will also attend each of the three 
different sprints’ daily Scrums, ensuring these are scheduled at different times, of course. 

In Figure 3.22, the Scrum environment is taken to a further level of complexity. There is still one 
product owner ultimately accountable for the product, but due to the size of the product, multiple 


assistant product owners have been assigned who need to coordinate the master product backlog 
items into the sprints, which are to deliver the required ‘definition of done’ (from each sprint and 
combined sprints). 

The LeSS website provides a rich resource of information for more complex Scrum projects. Note 
that as with all things Scrum, complexity is managed by breaking tasks down into increments and 
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sprints to deliver prioritised, highvalue, product backlog items into potentially shippable product 
increments (releases). 


3.9 DevOps 


DevOps is a relatively new approach emerging from two related trends. It aims to unify software 
development (Dev) and software operation (Ops), which are traditionally two independent functions 
of an ICT department. 

The need for DevOps arose from the increasing success of the Agile approach to software 
development, which led to development teams releasing software quicker and more frequently. This 
in turn placed more pressure on the release and support functions. As illustrated in Figure 3.23, the 
three components are: 


E development—very much an Agile (Scrum/lean) approach as documented in this chapter 


Em qualityeveraging process and practices of, for example, the ISTQB (International Software 
Testing Quality Board) 


E operations-here a ITIL (IT infrastructure library) approach to service management is often 
pursued, but in a lighter more agile manner. 


This approach is reported to: 


m make the development process more efficient, by linking software development to delivery 


™ create more stable operating environments as issues in the production environment are identified 
sooner and pushed back into the DevOps process 


Em improve team collaboration across the development, quality and service teams (serving the business) 
@ reduce times to market in contemporary fast-paced competitive environments. 
Further information on DevOps can be found at the DevOps Institute (https://devosinstitute.com). The 


story of DevOps is also documented in The Phoenix Project: A Novel about IT, DevOps, and Helping 
Your Business Win’, by Gene Kim, Kevin Behr & George Spafford (IT Revolution Press, 2016). 
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Figure 3.23 DevOps 
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This chapter has covered: 


the history of Agile, starting with the origins of the new product development game, which later became the 
inspiration for Scrum 

the Scrum framework, which includes the Scrum roles (product owner, Scrum master, development team and 
Scrum team), events (the sprint, the sprint planning meeting, the daily Scrum, the sprint review and the sprint 
retrospective) and the artefacts (the product backlog, the sprint backlog, the burndown/burnup charts, and the 
finished work) 

a brief insight into how both the PMI and PRINCE2 have recognised and adopted Agile concepts into their respective 
approaches to project management 

the acknowledgement that visual management (the Kanban board for example) is a key concept within the Agile 
approach. With geographically dispersed or complex projects, there may a requirementto use software Agile tools to 
assist with the management of an Agile approach 


an overview of how Scrum can be scaled by applying the LeSS framework 


how DevOps is taking elements of Scrum and integrating further with quality and operations to transform the 
traditional development through to production and services functions of an organisation. 


https://publications.axelos.com/Prince2Agile2015/content.aspx 

https://www.mountaingoatsoftware.com 

www.scrumguides.org 

https://www.mitchlacey.com/resources/official-scrum-guide-current-and-past-versions 

https://www.agilealliance.org 

http://agilemanifesto.org 

http://less.works 

https://www.agilealliance.org/glossar y/three-cs/#q=(filters~(post Type~(~’page~’post~’aa_bookn’aa_event_ 
session~’aa_experience_report~’aa_glossary~’aa_research_paper~’aa_video)vtags~(~’three*20cs))~searchTerme’~ 
sortefalsevsortDirection~’ascvpage~ 1) 

https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/sixth-edition 
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https://www.scruminc.com/scrum-blog/ 
https://www.astqb.org/how-testing-certification-makes-devops-successful/ 
www.projectmanagementinpractice.world 
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Review questions 


OOrNaAnawWn 


What are the Scrum roles and key expectations of each role? 

What are the Scrum artefacts, and what content does each contain? 

What are the Scrum events, when do they take place and what is the purpose of each event? 
How could Scrum be integrated with predictive project management techniques? 
What does MoSCoW mean and how is it used? 

What is the purpose of the Kanban or visual management board? 

How long does a daily Scrum take? 

How long would a sprint review take for a two-week sprint? 

What’s the relationship between an epic, increment, sprint and tasks? 

What’s the format for writing the front of story card? 

What does INVEST stand for? 

What is a burndown and burnup chart used for? 

What is sprint velocity and how can it be leveraged in sprint planning? 

What type of problems are Scrum (Agile) projects best suited for? 

What approach provides for the scalability of Scrum? 

What are the three key elements of a DevOps environment? 


For the class project (or a project of your choosing), consider how the Scrum approach would be applicable (or not) to 
the project. Create a list of eight points as to why you believe Scrum ‘would’ and/or ‘would not’ be suitable to use as 
an approach to ‘manage’ the project. 


For the class project, apply the MoSCoW prioritisation technique to the requirements you have identified at the 
initiation stage of the project. What does this tell you about the requirements that were collected? 


For a requirement you have prioritised as a ‘must have’, complete a story card — front and back, applying techniques 
learned in this chapter. 


Consider the Scrum roles and identify who would take on these roles if your project was to be managed with the 
Scrum approach. Comment on whether they have the correct skills to take on the role you allocated to them. 


What would you consider to be the right length of sprint for your project? Discuss with your group and present your 
discussion to the wider class. 
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Sarah, the Human Resources Manager, is approached by the Scrum master, Fred. Fred has heard that the human 
resource department is to undertake further development of the Human Resource Management System but all 
development is to take place using a Scrum (Agile) approach. Fred sits down with Sarah and starts to outline what her 
duties as a product owner will be, including asking whether Sarah has a product roadmap. Sarah does not, but she 
does have lots to say in relation to what the business and internal customers (or users) of the system are saying, and 
the features the vendor is promising in the next release. Fred, being a proactive Scrum master, discusses the issues 
with Sarah and starts to draft a product roadmap with her input and suggests she continues developing with input 
from the business. At the time of this first meeting, Fred has drafted a basic roadmap to capture Sarah's great ideas. 
On explaining the product backlog, Fred explains that in her work in producing the product roadmap, Sarah will 
initially feed the high-level stories for the product backlog, from which further detail will be added. Sarah now feels 
her ideas for the Human Resource Management System are being listened to and makes a commitment to further 
develop and maintain the product roadmap. 


Figure 3.24 Human ENET SWS e admap 
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Questions 


1. Using the above product roadmap with your own understanding of a Human Resource Management System and 
any additional research, build a partial product backlog for a feature of your choosing. 


2. Prioritise your product backlog using the MoSCoW technique. 


3. From the prioritised product backlog, design an appropriate sprint backlog for 20 story points of effort including 
some tasks (as if you were part of a development team). 
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4AA Further develop and understand the importance of the methods that define and 
align an organisation’s project activity. 
AB Understand the need for an Investment Business Case, and the detailed contents 
of a Business Case, including the financial models and non-financial criteria. 
AC Understand the features of portfolio management systems and the role of portfolio 
management. I 
$ 
} 
In this chapter 


E 4.1 Introduction 





4.7 Managing the portfolio management system 


4.8 Project portfolio management (PPM) 


m 4.2 Why project managers need to understand strategy 

4.3 The strategic management process: An overview 

m 4.4 The need for an effective portfolio, program and project management ‘system’ 
= 4.5 An introduction to portfolio management 


m 4.6 Applying a selection model 
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4.1 INTRODUCTION 


Strategy is (fundamentally) deciding how the organisation will compete. Organisations use projects to 
convert strategy into the new products, services and processes needed for success. For example, the 
major strategy of Intel® is one of differentiation. Its projects target innovation and time to market. 
Currently, Intel is directing its strategy towards specialty chips for products other than computers, 
such as cars, security, mobile phones, tablet computers and home automation. Another goal is to 
reduce project cycle times. Intel, Suncorp, General Electric®, Samsung™ and Apple have reduced 
their product cycle times by 20 to 50 per cent. Projects and project management. play the key role in 
supporting strategic goals. It is vital for project managers to think, and act, strategically. 

Aligning projects with the strategic goals of the organisation is crucial for project success. Today's 
economic climate is unprecedented in terms of rapid changes in technology, global competition, 
social cultures and financial uncertainty. These conditions make the quest for the strategic alignment 
of project activity even more essential for organisational success. Every major project needs to 
have a clear link to the organisation’s Strategic Plan. The larger and more diverse an organisation, 
however, the more difficult it is to create and maintain this strong link. Ample evidence still suggests 
that many organisations have not developed business processes that allow for the alignment of 
project selection from the strategic planning processes, which will result in poor utilisation of the 
organisation’s resources; for example, people, financial and equipment. Conversely, organisations that 
have a coherent link of projects (investments) to strategy tend to have more cooperation across the 
organisation, perform better, and have fewer failures. 

How can an organisation ensure this link and alignment? The answer involves the integration of 
projects with the Strategic Plan. Integration assumes the existence of a Strategic Plan and a process 
for prioritising investments by their contribution to the plan. A crucial factor to ensure the success of 
integrating the plan with projects lies in the creation of a process that is open and transparent for all 
participants to review. 

This chapter presents an overview of the importance of strategic planning and the links the 
project manager should be able to clearly describe for their projects. Problems that are typically 
encountered when strategy and projects are not linked are discussed. A generic methodology that 
ensures integration—b y creating very strong linkages of project selection and priority to the Strategic 
Plan—is also discussed. The intended outcomes are a clear organisational focus, best use of scarce 
organisational resources (people, equipment, resources and capital) and improved communication 
across projects and departments. 


4.2 WHY PROJECT MANAGERS NEED TO 
UNDERSTAND STRATEGY 


Project management has (historically) been preoccupied solely with the planning and execution of 
projects. Strategy was considered to be under the purview of senior management. However, this is 
‘oldschool’ thinking. ‘Newschool’ thinking recognises that project management is a key enabler of 
strategy. It is the authors’ belief that strategy is executed through the delivery of portfolios, programs 
and projects. 

There are two main reasons why project managers need to understand their organisation's mission, 
vision, values and strategic objectives. The first reason is so they can make appropriate decisions and 
adjustments. For example, how a project manager would respond to a suggestion to modify the design 
of a product to enhance performance will vary depending upon whether their company strives to be 
a product leader through innovation, or to achieve operational excellence through lowcost solutions. 
Similarly, how a project manager responds to delays may vary depending upon strategic concerns. A 
project manager will authorise overtime if their firm places a premium on getting the product/service 
to market first, whereas a different project manager may accept the delay if speed is not essential. 
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JP Descamps (1999) has observed that project managers who do not understand the role their 
project plays in accomplishing the strategy of their organisation tend to make the following serious 
mistakes: 


Em Focusing on problems or solutions that have low priority strategically. 
m Focusing on the immediate customer, rather than the whole marketplace and value chain. 


E Overemphasising technology as an end in, and of itself, resulting in projects that pursue exotic 
technology that does not fit the strategy or customer needs. 


Trying to solve every customer issue with a product or service rather than focusing on the 20 per 
cent that represent 80 per cent of the value (Pareto’s 80/20 rule). 


m Engaging ina never-ending search for perfection that no-one except the project team really 
cares about. 


The second reason project managers need to understand their organisation’s strategy is so they 
can be effective project advocatesthat is, they understand why the project has been given to them 
and the significance it has in contributing to the organisation's strategy. Protection and continued 
support come from being aligned with corporate objectives. Project managers also need to be able 
to explain to team members and other stakeholders why certain project objectives and priorities 
are critical. This is essential for getting buyin on contentious trade-off decisions. For these reasons, 
project managers will find it valuable to have a keen understanding of strategic management and of 
project selection processes. 


4.3 THE STRATEGIC MANAGEMENT PROCESS: 
AN OVERVIEW 


Strategic management is the process of assessing ‘what we are’ and deciding and implementing ‘what 
we intend to be’ and ‘how we are going to get there’. Strategy describes how an organisation intends 
to compete with the resources available in the existing and perceived future environment. This could 
be visualised using an extremely high-level ‘as-is’ (current) state and ‘to-be’ (future) state diagram 
(Figure 4.1). 

As Figure 4.1 illustrates, it is the astute choice and subsequent successful implementation of 
investments that move the business from the current state to a future state; this ‘state of play’ will 
be unpacked in this chapter. 


Figure 4.1 O s evi rent/fi 
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Two major dimensions of strategic management are: 


1. Responding to changes in the external environment. 


2. Allocating the firm's scarce resources to improve its competitive position. 


Constant scanning of the external environment for changes is a major requirement for survival 
in a dynamic, competitive environment. The second dimension is the internal responses to new 
programs that are aimed at enhancing the competitive position of the organisation. The nature 
of the responses depends on the type of business, environment volatility, competition and the 
organisational culture. 

Strategic management provides the theme and focus of the future direction of the organisation. It 
supports consistency of action at every level of the organisation. It encourages integration because 
effort and resources are committed to common goals and strategies. It is a continuous, iterative 
process, aimed at developing an integrated and coordinated longterm plan of action. Strategic 
management positions the organisation to meet the needs and requirements of its customers for 
the long term. With the longterm position identified, objectives are set and strategies are developed 
to achieve these objectives, which are then translated into actions by implementing programs and 
projects. Strategy can decide the survival of an organisation. Most organisations are successful 
in formulating strategies for what course(s) they should pursue. However, the problem in many 
organisations is implementing strategies-that is, making them happen. Moving from strategy 
formulation to strategy implementation (execution) can be the Achilles’ heel of a lot of organisations. 
The components of strategic management are closely linked, and all are directed towards the future 
success of the organisation. 

Strategic management requires strong links among mission, vision, values, strategic objectives, 
business plans and the projects that deliver them. The mission gives the general purpose of the 
organisation. Strategic objectives give global targets within the mission. Objectives give rise to 
formulation of tactical objectives to reach the strategic objectives. Finally, the tactical objectives 
require actions and tasks to be implemented. In most cases, the actions to be taken represent portfolios, 
programs and projects. Figure 4.2 shows a schematic of a simple strategic management process and 
major activities undertaken from a program and project perspective. 

There is a typical sequence of activities within the strategic management process. These are: 


1. Define and review the organisational mission, vision and values. 

2. Set the organisation’s strategic objectives. 

3. Analyse the strategic objectives and identify the ‘ideal’ investment mix. 

4. Implement the strategies through the delivery of portfolios, programs and projects. 


4.3.1 Define and review the organisational vision, 
mission and values 


The mission identifies ‘what we want to become’, or the raison d'être. Mission statements identify the 
scope of the organisation in terms of its product or service. A written mission statement provides focus for 
decision-making when shared by organisational managers and employees. Everyone in the organisation 
should be clearly aware of the organisation’s mission and how their role relates to the delivery of the 
organisation’s mission. The mission statement. communicates and identifies the purpose of the organisation 
to all stakeholders. Mission statements can be used for evaluating organisational performance. 
Traditional components found in mission statements are major products and services, target 
customers and markets, and the geographical domain. In addition, statements frequently include 
the organisational philosophy, key technologies, public image and contribution to society. Including 
such factors in mission statements relates directly to business success. Mission statements change 
relatively infrequently; however, when the nature of the business changes or shifts, a revised mission 
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Figure 4.2 
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statement may be required. For example, Steve Jobs (of Apple) envisioned the use of computer 
technology beyond the personal computer desktop. His mission was to look at computer technology 
as the vehicle for work and entertainment. As a result, the iPod was developed for selling music. Jobs 
also masterminded the development of animated movies such as Toy Story, Finding Nemo and others 
through the Pixar organisation. See Snapshot from Practice: Apple’s strategy to find out more about. 
how Apple’s mission shapes new product development projects. 

A mission statement differs from the more aspirational vision statement. The vision statement sets 
the long-term vision of the organisation and how the organisation will be seen within that industry. 

Values are the traits (typically shared beliefs) the company wishes to see in its employees. If the 
company openly exhibits these values, this fosters positive connections with the customer and sets the 
standard of cultural interactions the customer can expect to engage in with the organisation (as well 
as the interactions of the employees internally). Formulating strategy answers the question of ‘what’ 
the organisation wants to be, but not ‘how’ to achieve these strategic objectives. Strategy formulation 
includes determining and evaluating alternatives that support the organisation's objectives and selecting 
the best option. The first step is a realistic evaluation of the past and current position of the enterprise. 
This step typically includes an analysis of ‘who are the customers and what are their needs (as the 
customers see them)?’. This step often includes an assessment of the internal and external environments. 

What are the internal strengths and weaknesses of the enterprise, and the external threats and 
opportunities? A SWOT analysis is the starting place to explore these questions. Examples of internal 
strengths or weaknesses could include core competencies such as technology, product quality, 
management talent, low debt and dealer networks. Managers can alter (change and influence) internal 
strengths and weaknesses. Opportunities and threats usually act as external forces for change, such 
as advancement of technology, industry and competition. Competitive benchmarking tools are 
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SNAPSHOT FROM PRACTICE Apple's strategy 





When Steve Jobs returned to Apple Computer as its CEO 
in 1997, he became strikingly successful in developing 
a turnaround strategy that developed new markets and 
increased market share. It all began with a strict adherence 
to the mission statement: 


ray of Apple devices 





Apple is committed to bringing the best personal 
computing experience to students, educators, 
creative professionals and consumers around the 
world through its innovative hardware, software 
and Internet offerings. 





Shutterstock/Alexey Boldin 


The thrust of this turnaround strategy included mass 
customisation and targeting market segments. Apple's 
primary competitive advantage is that it controls both the 
hardware and software aspects of most of its products. 
The vision, coupled with this strong strategic advantage, 
allows Apple to offer innovation in hardware, software wm 
and internet offerings. Many product strategies were 
forged from their vision statement. For example, Jobs 
first segmented Apple's market into ‘consumer’ and 
‘professional. This segmentation reduced the number of m 
products and sharply targeted products to specific end- 
users. Several specific strategies were developed for the 
consumer market: for example, iTunes allows users to 


m high quality and innovative 


common architecture (which fits most products and 
eases development time) 


m free software 


ease of use 


a loyal customer base. 


For over 10 years, the string of innovative products 


collate a digital library of music and other media from the 
comfort and ease of their personal computer. Users can 
use iTunes to sync their music files across multiple devices. 

Apple's competitive advantages provide strong support 
for its product strategies; some of the more obvious are 
listed here: 


m control over both hardware and software (avoids 


released by Apple Inc. has been spectacular (and there 
appears to be no end.) Each new product endeavour 
closely aligns with Apple’s mission statement and current 
strategies. Launching new products in new markets 
requires executing projects within tight time, cost and 
scope constraints and Apple appears to understand this 
approach. 


compatibility problems) 


sometimes used here, to assess current and future directions. ‘®pportunities’ and ‘threats’ are the flip 
sides of each other. That is, a threat can be perceived as an opportunity, or vice versa. Examples of 
perceived external threats could be a slowing of the economy, a maturing product life cycle, exchange 
rates or government regulation. Typical opportunities are increasing demand, emerging markets and 
demographics. Managers or individual firms have limited opportunities to influence such external 
environmental factors. However, in recent years, notable exceptions have occurred such as Apple 
using the iPhone to create a market to sell online music. The key is to attempt to forecast fundamental 
industry changes and to stay in a proactive mode rather than a reactive one. 

SW@T is a basic strategic planning tool that can provide some perspective for an organisation to 
consider. ®@ther tools you may have heard of (or used) include: PESTEL, T@WS, Porter’s 5 Forces, Blue 
@cean Strategy, Kaplan and Norton (Strategy Maps and Balanced Scorecards )—to name but a few. The 
authors encourage you to further research these areas as new approaches are constantly emerging. 

Developing an organisation’s mission, vision and values is often a complex process in its own 
right. When agreed and promoted throughout the organisation, however, a ‘focused clarity’ can be 
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achieved for defining the business’s purpose. This can lead to better results because of the resulting 
tighter focus. Clear mission and vision statements decrease the chance of setting false directions by 
stakeholders, incorrect interpretation by customers and misunderstanding by employees. 


4.3.2 Set the organisation’s strategic objectives 


Strategic objectives translate the organisation’s mission and vision into specific, concrete, measurable 
terms. Strategic objectives set targets forall levels of the organisation. Objectives pinpoint the direction 
managers believe the organisation should move towards. Objectives answer in detail where a firm is 
headed and when it is going to get there. Typically, objectives for the organisation cover markets, 
products, innovation, productivity, quality, finance, profitability, employees and consumers. In every 
case, objectives should be as specific as possible. That is, objectives should include a timeframe, be 
measurable and be realistic. 

Each level below the organisational objectives should support the higherlevel objectives in more 
detail; this is frequently called ‘cascading’ of objectives. For example, if a firm making leather luggage 
sets an objective of achieving a 40 per cent increase in sales through a research and development 
(R&D) strategy, this charge is passed to the marketing, production and other departments. The R&D 
department accepts the firm’s strategy as its objective, and its strategy becomes the design and 
development of a new ‘pulHype luggage with hidden retractable wheels, and GPS location tracking’. 

It is useful to apply the SMARTA technique when defining strategic objectives. Objectives written 
using SMARTA (refer to Table 4.1) give rise to clear statements that progress can be tracked against; for 
example, to see how the organisation’s programs and projects are positively moving the organisation 
towards its mission. The objective suggested above, ‘achieving a 40 per cent increase in sales through 
an R&D strategy’, might be refined to ‘achieving a 40 per cent increase in sales on a baseline of 
A$50 million through a research and development strategy, bringing at least two new products to 
market, to be achieved within the 2019-20 financial year’. 


Table 41 SMARTA characteristics of objectives 


sS Specific Be specific in targeting an objective. Don't describe multiple objectives into one 
objective; separate them out into individual objectives. 


M Measurable Establish a measurable indicator(s) of progress (preferably with a baseline, so it 
can be later assessed as to what improvement has been delivered). 

A Assignable Make the objective assignable to one group of people for completion. 

R Realistic State what can realistically be achieved by the investment. This is a business 
reality check. 

T Time-bound State when the objective can be achieved, that is, the duration/date it is to be 
achieved by. 

A Agreed By all those accountable for delivering (sponsor, steering committee, project 


Manager and customer). 


A critical analysis of the strategies involves asking questions such as: 


Does the strategy take advantage of our core competencies? 
Does the strategy exploit our competitive advantage? 


Does the strategy maximise meeting customers’ needs? 


Does the strategy fit within our acceptable risk range? 


Once the strategic objectives are clarified, socialisation of these (along with the mission, vision and 
values) takes place. This cascading of strategy represents an important stage in ensuring a consistent 
understanding of where the organisation is going, and what each individual's role is in delivering the 
strategy. 


PART 2 POSITIONING PROJECTS 


4.3.3 Analyse the strategic objectives and identify the 
ideal investment mix 


From this analysis, critical issues, and a portfolio of strategic alternative investment areas, are identified. 
These alternatives are compared with the current portfolio and available resources. The portfolio of 
investments identified in support of the strategic objectives is a result of a complex process, potentially 
involving a line-up of business managers, program managers, and other subject matter experts. 

Some organisations will initiate an Investment Appraisal Business Case in support of these 
identified investment areas. The Business Case development starts in this step; it continues in 
the steps described below in 4.3.4 Implement strategies through portfolios, programs and projects. 
The Investment Business Case will often contain aspects such as: 


E Strategic alignment criteria detailing exactly what strategic objectives the investment aligns to 
and, when delivered, how much it will contribute (e.g. what is the expected impact on the key 
performance indicator(s) (KPIs) if the investment is delivered?). 


@ Definition of the business problem being solved and identification of constraints and assumptions. 
@ Benefits identification and analysis with the inclusion of a Benefit-Cost Ratio (BCR) calculation. 


Æ Options analysis including the ‘do nothing’ option, the deferred option, usually three other 
options, and the recommended option. 


@ Business risk analysis examining how the investment stacks up against the organisational risk 
context and the business risks identified through the analysis of corporate level risk. 


m Funding summary indicating ‘how’ and ‘from where’ the investment will be funded and 
detailing what the estimated cost and return on the investment will be often accompanied by 
net present value (NPV), internal rate of return (IRR) and BCR calculations for each option 
considered. 


@ Milestone summary indicating the approach and major components of work to be carried out. 
These usually result in the initial programs/projects, which, on approval of the Business Case, 
would (in effect) deliver its objectives. 


Once the Business Case has been prepared for each investment area, a validation check should 
take place to ensure there is continued alignment between the strategic objectives and the investment 
areas. After receiving appropriate approvals from the executive level, the Investment Business Case is 
carried forward into the next stage. 


4.3.4. Implement strategies through portfolios, programs and projects 


Implementation answers the question of how strategies will be realised, given available resources, 
equipment, change-tolerance and a host of other factors. The conceptual framework around 
strategy implementation can often lack the structure and discipline found in strategy formulation. 
Implementation requires the actioning and completion of tasks; the latter frequently means mission- 
critical projects, therefore, implementation must include attention to five key areas: 


1. Completing tasks will require allocating resources. Resources typically represent funds, 
people, management talents, technological competencies, and plant and equipment. Frequently, 
the implementation of projects is treated as an ‘addendum’ rather than an integral part of 
the strategic management process. However, multiple objectives (operational, strategic and 
mandatory) place conflicting demands on organisational resources. 

2. Implementation requires a formal organisation structure that complements and supports 
strategy and projects. Authority, responsibility and performance all depend on organisational 
structure and culture. 
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Strategy 


The strategy of the organisation. Common tools 

for exploration: 

e VMOST, establishing a clear vision, mission, 
objectives, strategies and tactics 

e Resource capability analysis 

e BCG matrix, for investment analysis 





Source: © 2018 Dr Neil Pearson 


3. Planning and control systems must be in place to be certain that project and program activities 
taking place are effectively performed, monitored and subsequently achieved. 


4. Motivating project contributors will be a major factor for achieving project/program success. 
An area receiving more attention in recent years is prioritising investments so that when 


delivered as programs and projects, the project manager knows how they are supporting the 
organisation's strategy. 


Although the strategy implementation process is not as clear as strategy formulation, all good 
managers realise that success is impossible without a solid implementation process. 

This section is summarised in Figure 4.4, where the linkages between the organisation’s external 
environment, strategy, portfolios, programs and projects are illustrated. 


4.4 THE NEED FOR AN EFFECTIVE PORTFOLIO, 
PROGRAM AND PROJECT MANAGEMENT SYSTEM 


As indicated in Figure 4.4, the implementation of projects without a strong portfolio and program 
management system, linked to strategy, creates problems. Three of the most obvious problems are 
discussed below. A portfolio management system can go a long way to reduce, or even eliminate, the 
impact of these problems. 


PART 2 POSITIONING PROJECTS 


4.4.1 Problem 1: The implementation gap 


In organisations with short product/service life cycles, it is interesting to note that repeated 
participation in frequent (quarterly) strategic planning and review meetings includes participants 
from all levels within the organisation. However, in perhaps 8@ per cent of the remaining product 
and service organisations, top management generally formulates strategy and leaves strategy 
implementation to the ‘functional’ managers. 

The functional managers develop more detailed strategies and objectives within these broad 
constraints. The fact that objectives and strategies are made independently at different levels by 
functional groups within the organisation hierarchy causes multiple problems. Some symptoms that 
an organisation is struggling with strategy disconnect and unclear priorities are presented here: 

Conflicts (about conflicting priorities) frequently occur among functional managers and cause a 
lack of trust. Frequent meetings are called to establish or renegotiate priorities. 

People frequently shift from one program/project to another, depending on the organisation's 
current priority. Employees are confused about which projects are therefore strategically important. 

People are working on multiple projects and feel inefficient. There is an inadequate focus on 
achieving outcomes and outputs within planned timeframes and budgets. The scope of work changes 
on a frequent basis and no longer delivers the Business Case upon which the work was approved to 
take place in the first place. 

Resources are not adequate to meet the demands of project and operational activities, and conflicts 
occur in trying to balance these limited resources across the two. 

Because clear linkages do not exist, the organisational environment becomes dysfunctional and 
confused and there is ineffective implementation of organisational strategy and thus, of programs 
and projects that are to deliver it. The implementation gap refers to the lack of understanding and 
consensus on organisational strategy among top managers, middle-level managers, and the employees 
who are responsible for delivering the work. 

An often-seen scenario is that top management picks its top (say, 20) projects for the next planning 
period, without priorities. Each functional department (marketing, finance, operations, engineering, 
information technology, and human resources) selects projects from the list. Unfortunately, 
independent department priorities across projects are not homogenous. A project that rates first in 
the IT department rates tenth in the finance department. Implementation of the projects generates 
perceived conflicts of interest, and levels of animosity develop over organisational resources. If this 
kind of situation exists, how is it possible to effectively implement strategy? This type of situation is 
serious. It is the authors’ experience that when consulting across many companies in many industries, 
there is frequently a misalignment between the strategic direction of a company and the work 
(investments, portfolios, programs and projects) that are currently taking place in the organisation. 

Middle managers often consider organisational strategy to be under the purview of others, or not 
within their realm of influence. It is the responsibility of senior management therefore to set policies 
that show a distinct link between organisational strategy and objectives and projects that implement 
those strategies. 


4.4.2 Problem 2: Organisational politics 


‘Politics’ exist in every organisation and can significantly influence which projects receive funding and 
high priority (and conversely, which do not). This is especially true when the criteria and processes for 
selecting investments are illdefined and are not aligned with the firm's mission. Investment (project) 
selection may be based not so much on facts and business drivers, but rather on the persuasiveness 
and power (the ‘squeaky wheel syndrome’) of people advocating for a particular investment. 

The term ‘sacred cow’ is often used to denote a project that a powerful, high-ranking executive is 
advocating for. A marketing consultant once explained how he was hired by the marketing director 
of a large firm to conduct an independent, external market analysis for a new product the firm was 
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interested in developing. His extensive research indicated there was insufficient demand to warrant 
the financing of this new product. The marketing director however, chose to bury the report, and 
made the consultant promise never to share this information with anyone. The director explained how 
the new product was the pet idea of the new CEO (who saw it as his legacy to the firm). The marketing 
director went on to describe the CEO's irrational obsession with the project and how he referred to it 
as his new baby. The marketing director believed that he would lose his job if such critical information 
ever became known. Ethics and transparency did not come into this discussion—in a modern project 
organisation these situations should never arise. 

Project sponsors can play a significant role in the selection and successful implementation of 
product innovation projects. Project sponsors are typically highranking managers who endorse 
and lend political support for the completion of a specific project. They are instrumental in winning 
approval for the project and protecting it during the critical development stage. Savvy project 
managers recognise the importance of having ‘friends in higher courts’ who can advocate for their 
case and protect their interests. 

The significance of corporate politics can be seen in the often quoted and ill-fated ALTO computer 
project at Xerox during the mid-197@s. The project was a tremendous technological success; it. 
developed the first workable mouse, the first laser printer, the first userfriendly software and the 
first local area network (LAN). All of these developments were five years ahead of their nearest 
competitor. Over the next five years the opportunity to dominate the nascent personal computer 
market was squandered because of internal infighting at Xerox and the absence of a strong project 
sponsor. Bill Gates stepped into the market after seeing developments at Xerox, as did Steve Jobs, and 
as they say ‘the rest is history’. 

Politics can play a role not only in project selection but also in the aspirations behind projects. 
Individuals can enhance their power within an organisation by managing extraordinary and critical 
projects. Power and status naturally accrue to successful innovators and risktakers rather than to 
steady producers. Many ambitious managers pursue highprofile projects as a means for moving 
quickly up the corporate ladder. For example, Lee Iacocca’s career was built on successfully 
leading the design and development of the highly successful Ford® Mustang. Managers become 
heroes by leading projects that contribute significantly to an organisation’s mission or solve a 
pressing crisis. 

Many would argue that politics and project management should not mix. A more proactive 
response is that projects and politics invariably mix and that effective project managers recognise 
that any significant project has political ramifications. Likewise, top management needs to develop a 
system for identifying and selecting projects that reduce the impact of internal politics and foster the 
selection of the best projects for achieving the mission and strategy of the firm. 


4.4.3 Problem 3: Resource conflicts and multitasking 


Most project organisations exist in a multiproject environment. This environment creates problems 
of project interdependency and the need to share resources. For example, consider what. the potential 
impact would be on the labour resource pool of a (mediumsized) construction company, should it. win 
a contract it would like to bid on when it is already heavily committed to other projects. Will its existing 
labour force be adequate to deal with the new pro ject—given the completion date? Will current projects 
be delayed? Will subcontracting help? Which projects will have priority? Competition among project 
managers can be contentious. All project managers seek to have the best people for their projects. The 
problems of sharing resources and scheduling resources across projects grows exponentially as the 
number of projects rises. In multiproject environments, the stakes are even higher and the benefits, 
or penalties, for ‘good’ or ‘bad’ resource scheduling become even more significant than in most single 
projects. Resource sharing also leads to multitasking. Multitasking involves starting and stopping 
work on one task to work on another project and then returning to the original task. People working 
on several tasks concurrently are far less efficient, especially where conceptual or physical shutdown 
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and startup are significant. Multitasking adds to delays and costs; changing priorities exacerbate 
the multitasking problems. Likewise, multitasking is more evident in organisations that have too 
many projects for the resources they command. The number of projects in a portfolio almost always 
exceeds the available resources (typically by a factor of three to four times). This capacity overload 
inevitably leads to confusion and the inefficient use of scarce organisational resources. The presence 
of an implementation gap, power politics and multitasking add to the problem of which projects are 
allocated resources first. Employee morale and confidence suffer because it is difficult to make sense 
of an ambiguous system. A multi-progranvproject organisation environment faces major problems 
without. a priority system that is clearly linked to the Strategic Plan. So, what can be done? 

The first and most important change that will go a long way in addressing these and other 
problems is the development and use of a meaningful pre ject prierity precess for project selection; 
such a system should answer questions such as: 


1. How can the implementation gap be narrowed so that understanding and consensus on 
organisational strategies run through all levels of management? That is, how is strategy cascaded 
through the organisation? 


bo 


How can power politics be minimised? 
Can a process be developed in which investments (programs/projects) are consistently prioritised 
to support organisational strategies? 


4. Can the prioritised investments be used to allocate scarce organisational resources—fo r example, 
people and equipment? 


a 


Can the process accommodate bottom-up initiation of ideas (that later become projects) that 
support and align with the organisation's strategy? 


What is needed is a set of integrative criteria and a process for evaluating and selecting projects 
that best support the higher-level strategies and objectives that can be resourced. A single-project 
priority system that ranks projects by their contribution to the Strategic Plan would make life easier. 
Easily enough said, but difficult to accomplish in practice. Organisations that manage independent 
programs and projects and allocate resources in an ad hoc manner have shifted focus to selecting the 
right portfolio of programs and projects (investments) to achieve their strategic objectives. This is an 
accelerating trend. The advantages of successful portfolio management systems are becoming well 
recognised in project-driven organisations. See Table 4.2, which lists a few of the key benefits (note 
that this could easily be extended). 


Table 4.2 Key benefits of portfolio management systems 


m Build discipline into program and project selection and prioritisation process. 

m Prioritise program and project proposals across a common set of criteria, rather than based on politics or emotion. 

m Manage dependencies across the set of programs and projects. 

m Facilitate budget tracking across the portfolio of programs and projects. 

m Justify ‘killing’ (prematurely closing) programs and projects that do not or no longer support the organisation’s 
strategy. 

m Improve communication and support agreement on program and project goals. 

m Enable a holistic view of risk and the impact this may have on the organisation to be taken across a portfolio. 

m Enable an ‘apples with apples’ comparison due to a common approach to the financial returns of investments. 

m Enable resources to be optimised across the entire portfolio, thereby ensuring proactive use of often-scarce 


resources. 
Build strategically aligned portfolios, increasing success in the execution of strategy. 


m Formalise decision-making into a process that transparently and fairly allows for discussion, debate and confirmation 
of the investments to be undertaken prior to executing the portfolio through programs and projects. 


A portfolio management system is discussed next, with an emphasis on selection criteria (which is 
where the power of the portfolio system is established—4.e. selecting the correct investments, which 
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are later packaged as programs and projects). We normally refer to the ‘idea’ for a program or project 
at this level as an ‘investment’. Once an investment has been approved, it will be placed into a structure 
within each portfolio (and an organisation typically has multiple portfolios) and there will typically be 
a number of programs and projects that deliver each portfolio. 


4.5 AN INTRODUCTION TO PORTFOLIO MANAGEMENT 


Succinctly put, the aim of portfolio management is to ensure that investments are aligned with strategic 
goals and are prioritised appropriately. As Foti (2002) points out, portfolio management needs to 
elicit the rhetorical question ‘What is strategic to our organisation?’ Portfolio management provides 
information that allows people to make better business decisions. Since investments typically compete 
for funding and people usually outnumber available resources, it is important to follow a logical and 
defined process for selecting which investments (programs and projects) to implement. The design of 
a portfolio system should include (at minimum) the classification of investment(s), selection criteria 
depending upon classification, sources of proposals, proposal evaluations and managing the portfolio 
of programs and projects. 


4.5.1 Classification of investments 


Many organisations find they have three different kinds of investments in their portfolio: compliance 
and emergency (1must-do) investments, operational investments and strategic investments. 


1. Cempliance investments are typically those that are needed to meet regulatory conditions 
or legal compliance; hence, they are called ‘must-do’ investments. Emergency work, such 
as rebuilding a warehouse that has been destroyed by floods, meets the ‘must-do’ criteria. 
Compliance and emergency programs/projects usually have penalties if they are not 
implemented. 

2. Operatienal investments are those that are needed to support current operations. These 
investments are designed to improve efficiency of operational systems and processes, reduce 
product costs and improve performance. Continuous improvement (CI) (sometimes referred to as 
business improvement) investments are examples of operational projects. 

3. Strategic investments are those that directly support the organisation's vision, mission, objectives, 
strategies and tactics. They are frequently directed towards increasing revenue, market share, or 
customer retention/satisfaction. Examples of strategic investments are new products, research 
and development, or changing the way the business operates. Refer to Table 4.3. 


Table 4.3 Some examples of compliance (must-do), strategic and operational 


investments 
Category | Theme Investment 
Compliance Workplace health and safety Implement fully RIDDOR—Reporting of Injuries, Diseases and 
Dangerous Occurrences Regulations 2013 (UK) 
Financial Implement EU General Data Protection Regulation 
Financial Implement updated Company Director Guidance 
Financial Ensure compliance with the Australian Consumer Law (ACL) 
Strategic Customer Review competitor product and customer complaints and create a 
better aligned service 
Market Introduce a new service to compete with competitor offerings 
Research and Research the impact of loT (the Internet of Things) on existing 
development (R&D) products to enable delivery of this functionality 
Operational Process Improve the recruitment process and shorten the lead-time 


to employment 
Equipment Replace ageing elevators with a more energy-efficient solution 
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Most organisations that carry out strategic alignment of investments will use a portfolio or 
investment management solution to assist them in this prioritisation activity. The strategic value 
of a proposed investment must be determined before it can be placed in the portfolio. Under some 
circumstances, there are investments that ‘must’ be selected. These compliance (typically legal, 
government. or legislation) or ‘emergency’ investments are those that must be implemented or the 
firm will fail or suffer dire penalties or consequences (e.g. where a manufacturing plant must install 
an electrostatic filter on top of a smokestack within six months or close down, or where loss of life or 
injury has occurred and practices need to be adjusted as a matter of urgency). European Union courts 
are trying to force Microsoft® to open its software architecture to allow competing software firms to 
be compatible and interact with Microsoft. This decision may become a compliance piece of work for 
Microsoft. Any project placed in the ‘must’ category ignores other selection criteria. A rule of thumb 
for placing a proposed project in this category is that most of the organisation's stakeholders would 
agree that the project must be implemented; there is no perceived choice but to implement the project. 
All other projects are selected using selection criteria linked to an organisation's strategy. 


4.5.2 Selection criteria 

Although there are many criteria for selecting projects, selection criteria are typically identified as 
financial and nonfinancial. A short description of each is given next, followed by a discussion of 
their use, in practice. Remember that these financial calculations can be carried out for a number of 
situations the project manager may find themselves in, for example to: 


1. compare options within a Business Case 


to 


compare two or more investments for strategic prioritisation 


3. make decisions about which terms to accept from a supplier. 


Financial criteria 


Financial medels Many managers prefer using financial criteria models to evaluate investments. 
These models are appropriate when there is a high level of confidence associated with estimates of 
future cash flows. Three models and examples are demonstrated here: payback, net present. value 
(NPV), internal rate of return (IRR), and benefit-cost ratio (BCR). 

Investment A has an initial investment of $700 000 and projected cash inflows of the same amount 
of $225 000 for five years. 

Investment B has an initial investment of $400 000 and projected cash inflows of the same amount 
of $110 000 for five years. 


1. The payback model measures the time it will take to recover the project investment. Shorter 
paybacks are more desirable. Payback is the simplest and most widely used model. Payback 
emphasises cash flows: a key factor in business. Some managers use the payback model to 
eliminate unusually risky projects (those with lengthy payback periods). The major limitations 
of payback are that it ignores the time value of money, assumes cash inflows for the investment 
period (and not beyond) and does not consider profitability. The payback formula is: 


Payback period (years) = Estimated projectcost / Annualsavings 


Figure 4.5A compares the payback for Investment A and Investment B. The payback for Investment A 
is 3.1 years and for Investment B is 3.6 years. Using the payback method, both investments are 
acceptable, since both retum the initial investment in less than five years (the baseline set of the finance 
controller for this business). 

They also have returns on the investment: Investment A 32.1 per cent, and Investment B 
27.5 per cent. 
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Figure 4.5A calculations in Micr t® Excel 
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Figure 4.5B The NPV model using Microsoft® Excel 










+ Discount 


















































































































































rate (set by 
the business) * Investment cost = Cash in-few or 
inyear 0 benefits (savings) 
received for 
| subsequent years 
A—] =e) E n |_T B SSS a he P 
1 
2 
3 [Discount rate 015 Jf 15%) Disceunt rate ©.15 (ie 015%) 
ao] 
smana A m a ce 
6 [Cash flow $225,000 08 | $225,000.08 |$225.00000 [Cash mw |s; 90 |$ 110.0001 . 
7 m | «= PV Year a a m 
8 |_| | iii |l ah | Í 
| $93175 20| <= Ssa3475 00 | | | | 
115 i | $72,326.79 | 79 | | 
si zebas 48 tl | $52.89285 a6 Í 
missa 77 | $54,689.44 | < $5,999.44) 
19 [Biscount tacter 108 087 050 [Discountracter 100 oa? 076 0.665 057 e50 









































* Discount factor 


s NPV calculation 
calculation 


=C6°C19 


=1(14$B$3)"1 





Source: @ 2018 Dr Neil Pearson 


Given the payback and return on investment (rate of return), Investment A is looking like the 
preferred option at this point. However, if the time value of money is considered (i.e. money received in 
the future is worth less than it is today because of devaluation) how does this now affect our decision? 
2. The net present value (NPV) model (Figure 4.5B) uses management’s minimum desired discount 

rate, e.g. 15 per cent to calculate the present value of all net cash inflows (i.e. the net present 
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value)—the calculations take into account that. money over time devalues and we have to 
consider that in the selection of which are the best investment(s) to go forward with. 


Note: The discount rate is a complex calculation affected by many factors including what rate the 
business can borrow funds (money) at, in order to finance the investments it wishes to make. 

If the NPV result is positive, it is eligible for further consideration. If the result. is negative, the 
project is rejected. Thus, investments with higher positive NPVs are desirable. 

The NPV is the sum of all the planned values (PV). The individual yearon-year PVs are calculated 
by (e.g. see Year 5 in Figure 4.5B): 


1. taking the Year 5 benefit (savings) of $225 000 
2. calculating the ‘discount rate’ to the power of the year the benefit. is occurring infor example, 
15% discount would calculate out as: 1/(1 + 0.15)° = (as the benefit in the example is in Year 5) 
= 0.50 
3. dividing the Year 5 benefit amount by this number, for example, 225 000 / 0.50 = 195 652.17 (this is 
what the Year 5 money would be worth today.). 
The NPV model accepts Investment A, which has a positive NPV of $54 235. Investment B is rejected 
since the NPV is minus $31 263. 





Compare the NPV results with the payback results. The NPV model is more realistic because it 
considers the time value of money, cash flows and profitability. When using the NPV model, the 
discount rate (return on investment or ROI) can differ for different projects. For example, the expected 
ROI on strategic projects is frequently set higher than operational projects. Similarly, ROIs can differ 
for riskier versus safer projects. The criteria for setting the ROI hurdle rate should be clear and applied 
consistently. 

From the NPV calculation(s), it is then possible to calculate the internal rate of return (IRR). The 
IRR is a metric used in capital budgeting measuring the profitability of potential investments. IRR is a 
discount rate that makes the NPV of all cash flows from a particular investment equal to zero. 

Because of the nature of the formula, however, IRR cannot be calculated analytically, and must 
instead be calculated either through trial and error or using software tools, such as Microsoft Excel. 
Generally speaking, the higher the IRR, the more desirable it is to undertake the investment. (so long 
as it is above the organisation’s hurdle rate). IRR is uniform for investments of varying types and, as 
such, IRR can be used to rank multiple prospective investments (projects) a firm is considering on 
a relatively even basis. Assuming the costs of investment are equal among the various projects, the 
project with the highest IRR would probably be considered the best and undertaken first. Refer to 
Figure 4.6. 


4. The benefit-cost ratio (BCR) model provides a simple ratio of the benefits to be delivered by the 
investment (across the product life cycle of the investment/project) against the cost to deliver 
those benefits (e.g. the cost of the investment/project). The formula for BCR is: 


Benefit cost ratio = Defined benefit (value) / Cost of the project (investment) 


Using the same investments, Figure 4.7 again confirms that the higher BCR of Investment A means 
that Investment A would be the preferred investment to take forward over Investment B. 

A positive whole number is good; it represents that the money invested returns greater value in 
benefits delivered to the organisation. A negative number is bad, as costs would outweigh the benefits. 


CHAPTER 4 ORGANISATIONAL STRATEGY AND PROJECT SELECTION 


Figure 4.6 IRR calculation 
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Figure 4.7 Benefit-cost ratio (BCR) 
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Unfortunately, pure financial models fail to include many projects where financial return is 
impossible to measure and/or other factors are vital to the ‘accept’ or ‘reject’ decision. One research 
study by Foti (2002) showed that companies using predominantly financial models to prioritise 
projects yielded unbalanced portfolios and projects that were not strategically oriented. Other studies 


make similar claims. 
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The general decision criteria for each model are summarised in Table 4.4. 


Table 4.4 Summary of financial models 


Technique Looking for. . . 

Payback The sooner, the better. 

Rate of return The higher the percentage, 
the better. 

NPV Must be positive. 


The higher the number, the better. 


IRR The higher the percentage, the 
better. 
BCR The higher the number, the better. 


Ratio must be greater than 1. 


Comment 
Values after the payback year are ignored. 


There may be an organisational threshold over which the 
percentage must be. 

Takes into consideration the time value of money. 
Negative numbers indicate investments should not be 
backed. 

There may be an organisational threshold (bar) over which 
the percentage must be. 

BCR values less than 1 indicate the project’s costs 
outweigh the benefits. 


Considers qualitative factors (benefits) which are given a 
quantitative value. 


Non-financial criteria 


Financial return, while important, does not always reflect strategic importance. The 196@s and 1970s 
saw firms become overextended by diversifying too much. Now the prevailing thinking is that long- 
term survival is dependent upon developing and maintaining core competencies. Companies have 
to be disciplined enough to ‘say no’ to potentially profitable investments that are outside the realm 
of their core mission. This requires other criteria be considered beyond direct financial return. For 
example, a firm may support investments that do not have high profit margins for other strategic 
reasons including to: 


capture larger market share 

make it difficult for competitors to enter the market 

develop an ‘enabler product’, if its introduction will increase sales in more profitable products 
develop core technology that will be used in next-generation products 


reduce dependency on unreliable suppliers 


prevent government intervention and regulation. 


Organisations may support projects to restore corporate image or enhance brand recognition. 
Many organisations are committed to corporate citizenship and support community development 
projects. Since no single criterion can reflect strategic significance, portfolio management requires 
multi-criteria screening models. These models often weight individual criteria so those projects that 
contribute to the most important strategic objectives are given higher consideration. 


4.5.3 Multi-criteria selection models 

Since no single criterion can reflect strategic significance, portfolio management requires multi- 
criteria screening models. Two such models, a checklist. and multi-weighted scoring models will be 
described next. 


Checklist models 

The most frequently used method for selecting projects has been the checklist. This approach basically 
uses a list of questions to review potential projects and to determine their acceptance or rejection. 
Several examples of questions typically encountered in practice are listed in Table 4.5. 
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Table 4.5 Sample selection questions used in practice 


Topic Question 


Strategic alignment What specific organisational strategy does this investment align with? 
Driver What business problem does the investment solve? 

Success metrics How will we measure success? 

Sponsorship Who is the investment sponsor? 

Risk What is the impact of not doing this investment? 

Risk What is the investment risk to our organisation? 

Risk Where does the proposed investment fit in our risk profile? 
Benefits, value, ROI What is the value of the investment to this organisation? 
Benefits, value, ROI When will the investment show results? 

Benefits, value, ROI What is the opportunity cost? 

Objectives What are the investment objectives? 

Organisational culture Is our organisational culture right for this type of investment? 
Resources Will internal resources be available for this investment? 
Approach Will we make (build) or buy? 

Schedule What are dependencies with other investments? 

Schedule Is the timeline realistic? 

Training/resources Will staff training be required? 

Finance/portfolio What is the estimated cost of the investment? 

Portfolio Is this a new initiative or part of an existing initiative? 
Portfolio How does this investment interact with current investments? 
Technology Is the technology available or new? 

Organisational change impact What is the organisational change impact of the investment? 
Organisational change impact Does the organisational structure require changing? 


A justification for checklist models is that they allow great flexibility when selecting from many 
different types of projects, and are easily used across different divisions and locations. 

Although many projects are selected using a variation of the checklist approach, there are some 
serious shortcomings in this approach that the reader should bear in mind. Major shortcomings of 
this approach are that it fails to answer the relative importance or value of a potential project to 
the organisation, and fails to allow for comparison with other potential projects. Each potential 
project will have a different set of positive and negative answers. How do you compare? Ranking 
and prioritising projects by their importance is difficult, if not impossible. This approach also leaves 
the door open for potential power plays, political manoeuvrings and other forms of manipulation. To 
overcome these serious shortcomings, experts recommend the use of a multi-weighted scering model 
to select projects. This is examined next. 


Multi-weighted scoring models 


A ‘weighted’ scoring model typically uses several weighted selection criteria to evaluate project 
proposals. Weighted scoring models will generally include qualitative and/or quantitative criteria and 
each selection criterion is assigned a ‘weight’. Scores are assigned to each criterion fer the project, 
based on its importance te the project being evaluated. The weights and scores are multiplied to get 
a total weighted score for the project. Using these multiple screening criteria, projects can then be 
compared using the weighted score. Projects with higher weighted scores are considered better. 

Selection criteria need to mirror the critical success factors of an organisation. For example: 3M 
set a target that 25 per cent of the company’s sales would come from products fewer than four years 
old, versus the ‘old’ target of 20 per cent. The company’s priority system for project selection strongly 
reflected this new target. 

Failure to pick the ‘right factors’ will however render the screening process useless. See Snapshot 
from Practice: Crisis IT. 
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Figure 4.8 represents a project-scoring matrix that uses some factors usually found in practice. The 
selected screening criteria are shown across the top of the matrix (e.g. stay within core competencies, 
ROI of 18 per cent plus). Management weights each criterion (a value of 0 to a high of say, 3) by its 
relative importance to the organisation’s objectives and Strategic Plan. Project proposals are then 
submitted to a project priority team or the project portfolio office. 

Each proposal is next evaluated by its relative contribution/value added to the selected criteria. 
Values of 0, to a high of 10, are assigned to each criterion for each project. This value represents 
the fit to the specific criterion. For example, Project 1 appears to fit well with the strategy of the 
organisation since it is given a value of 8. Conversely, Project 1 does nothing to support reducing 
defects (its value is 0). Finally, this model applies the management weights to each criterion by 
importance-using a value of 1 to 3. For example, ‘ROI’ and ‘strategic fit’ have a weight of 3, while 
‘urgency’ and ‘core competencies’ have weights of 2. Applying the weight to each criterion, the priority 
team derives the weighted total points for each project. For example, Project 5 has the highest value of 
102 [(2 x 1) + (8 x 10) + (2 X 5) + (2.5 x 10) + (1 x 0) + (1 x 8) + (8 x 9) = 102] and Project 2 has 
a low value of 27. If the resources available create a cutoff threshold of 50 points, the priority team 
would eliminate Projects 2 and 4. (Note: Project 4 appears to have some urgency, but it is not classified 
as a ‘must’ project. Therefore, it is screened with all other proposals.) Project 5 would receive first 
priority, Project n second, and so on. In rare cases where resources are severely limited and project 
proposals are similar in weighted rank, it is prudent to pick the project that places less demand on 
resources. Weighted multiple criteria models similar to this are rapidly becoming the preferred choice 
for prioritising projects. 

At this point in the discussion it is advisable to pause and put things into perspective. While 
selection models like the one above may yield numerical solutions to investment selection decisions, 
models should not make the final decisions—th e people using the models should. No model, no matter 
how sophisticated, can capture the total reality it is meant to represent. Models are tools for guiding 
the evaluation process, so the decision-makers will consider relevant issues and reach a ‘meeting of 
the minds’ regarding which projects should be supported, and not supported. This is a much more 
subjective process than calculations suggest. 
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SNAPSHOT FROM PRACTICE Crisis IT 





In May 2007, Frontier Airlines Holdings (United States) 
hired Gerry Coady as its Chief Information Officer (CIO). 
Nearly a year later, the airline filed for bankruptcy under 
Chapter 11. In an interview Coady described how he 
managed IT projects during the bankruptcy and recession 
crisis of 2008-09. Fundamentally, Coady faced a situation 
of ‘too many projects’ and ‘too few resources’. Coady 
had used a strategy of focusing on reducing the number 
of projects in the portfolio. He put together a steering 
committee of senior management that reviewed several 
hundred projects. The end result was a reduction to less 
than 30 projects remaining in the portfolio. 


How can you get to a backlog of over 100 
projects? 

‘There are never enough resources to get everything 
done. Backlogs build over time. ‘Sacred cow’ projects 
get included in the selection system. Projects proposed 
from people who have left the airline still reside in the 
project portfolio. Non-value-added projects somehow 
make their way into the project portfolio. Soon the queue 
gets longer. With everyone in IT working on too many 
projects concurrently, project completion and productivity 
are slow. 


Which projects remain? 

To cut the number of projects, the steering committee 
used a weighting scheme that reflected the airline’s 
priorities, which were: fly safe, generate revenue, reduce 
costs and provide customer service. The weighting 
scheme easily weeded out the ‘fluff. Coady noted that ‘by 
the time you get to the 20s, the margin of differentiation 
gets narrower and narrower’. Of the remaining projects, 
the project sponsors had to be able to solidly justify why 


Figure 4.9 ent at Frontier Airlines 
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their project was important. A reduction in the number 
of projects places the emphasis on high-value projects. 


What advice did Coady have for crisis 
management? 


Coady argued that in times of crisis, it is easier to take 
bold steps to make changes, but you need to have a 
clear vision of what you should be focusing on with the 
resources available. Coady suggested that realistically it 
comes to ‘having a good idea of what the initial business 
case for a project is and what resources it is consuming, 
both people and otherwise’. 


Source: Adapted from Worthen B 2008, ‘Crisis IT’, The Wall Street Journal, 
20 April, p. R@. 


Pair-wise criterion (analytic hierarchy process) 


Here, a model based on the analytic hierarchy process (AHP) is applied. The steps are outlined 
below, but in reality, form a complex process that is best applied with the assistance of software tools. 
In summary, steps include: 


Step 1: A list of criteria is established against which the investments (programs and/or projects) 
are to be assessed. This list could consist of many and varied criteria, for example, aspects of 
financial safety, market share, strategic alignment. and legislation could be among a set of criteria 
an organisation uses to assess the relative ranking of investments. 


Step 2: The executive management team (individually) votes on the relative importance of each 
criterion against each of the other criteria, using a pairwise method. 

Step 3: The executive management team (individually) ranks the list of investments (programs and/ 
or projects) against the list of criteria. 
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Step 4: The output of these processes is a prioritised list of investments, based on the weighted set of 
criteria. 


This can be a complex process, but has been proven to assist organisations of all sizes across 
varied industries in this complex area of decision-making. Some portfolio management systems 
include prioritisation tools within their software that. are based on the pair-wise criterion method (e.g. 
Primavera). Other tools, such as Decision Lens (www.decisionlens.com), specialise in providing software 
and processes that apply this technique across various decisionmaking contexts in an organisation. 


Nominal group technique (NGT) 


Another technique also commonly encountered in portfolio prioritisation is the nominal group 
technique (NGT)—viewed as a simple, perceptions-based technique for investment (progranVproject) 
selection. NGT is a simple prioritisation technique that helps to take out ‘bias’ of ‘vocal’ members of the 
voting community. NGT is a simple series of steps usually carried out in a brainstorming workshop, 
as follows: 


Step 1: The group is asked for input to creating a list of the items (programs/projects) to be 
prioritised. The group should be facilitated so only the content of the list is brainstormed, and not 
the perspectives or opinions of the individuals in the room. The facilitator must also ensure the 
group understands any item added to the list. 

Step 2: The individuals in the group (anonymously) next prioritise the list as: 1st, 2nd, 3rd etc. (no 
duplicate priorities can be used). 

Step 3: The facilitator collects the individual lists and totals the scores. As Ist is the lowest 
numerically, the project with the lowest total score will be the project that tops the list (and so on, 
down the totals). 


The result is a prioritised, perceptions-based list of programs/projects. When setting the ground 
rules prior to going into the meeting, it would need to be declared and emphasised that the resulting 
‘group vote’ would be the list that would be taken forward for further development by the portfolio 
management office. Although lacking in a quantitative basis, NGT can provide a perspectives-based 
list that is pivoted around experience or the ‘gut feeling’ of a team of executives (or other managers) 
about what they perceive to be important investments to pursue. Even if only used as a tool to validate 
and/or question other methods, NGT is useful. 

When applied to an example, the steps would panout as: 


Step 1: The facilitator requests a group of six executive managers to attend a briefing session to 
prioritise the eight key strategic programs for the year, as determined by the strategic planning 
process. The list of the eight strategic programs looks like this: 





A | Implement a customer relationship management system (including business processes, 
systems and training). 





B | Develop two new products and market test to ensure continuity of products in the 
marketplace. 





C | Grow market share by 15% on a baseline of 33%. 





D | Implement social media strategies and technologies across all products and services offered. 





E | Update the Enterprise Resource Planning (ERP) system to the latest version to ensure 
continued software support arrangements can be entered into. 





F | Reduce employee headcount by 10% through implementation of efficiency programs. 





G | Relocate to a greenfield sustainable technology park to reduce overheads by 10%. 





H | Remove one executive management position and five direct management positions to flatten 
the organisational structure, in line with competitors. 
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In this step, each investment area (project) is discussed to ensure the achievement of a common 
understanding. The facilitator steers discussion to ensure that personalities, politics, and personal 
perspectives are kept out of the discussion. 

Step 2: After a common understanding of the programs is achieved, each of the individual executive 
managers is asked to vote (in confidence). For example, the CFO's vote could potentially look 
like: 





























CFO voting slip 

A Implement a customer relationship management system (including business ul 
processes, systems and training). 

B Bevelop two new products and market test to ensure continuity of products in 3 
the market place. 

Cc Grow market share by 15% on a baseline of 33%. 

B Implement social media strategies and technologies across all products and 2 
services offered. 

E Update the ERP system to the latest version to ensure continued software support 6 
arrangements can be entered into. 

F Reduce employee headcount by 10% through implementation of efficiency 8 
programs. 

G Relocate to a greenfield sustainable technology park to reduce overheads by 10%. 

H Remove one executive management position and five direct management 














positions to flatten the organisational structure, in line with competitors. 





Step 3: The facilitator now collects the voting slips from all the participants, tallies the scores, and 
reveals the totals to the group. The resulting list of priorities could be as shown below: 

















Investment area (program/project) Overall group 
priority 

A Implement a customer relationship management system (including 16 
business processes, systems and training). 

B Bevelop two new products and market test to ensure continuity of 18 
products in the marketplace. 

Cc Grow market share by 15% on a baseline of 33%. 19 

B Implement social media strategies and technologies across all products 20 


and services offered. 





E Update the ERP system to the latest version to ensure continued 25 
software support arrangements can be entered into. 





F Reduce employee headcount by 10% through implementation of 33 
efficiency programs. 





G Relocate to a greenfield sustainable technology park to reduce 39 
overheads by 10%. 





H Remove one executive management position and five direct 46 
management. positions to flatten the organisational structure, in line 
with competitors. 

















In this example, Investment A—Implement a customer relationship management system 
(including business processes, systems and training)—was voted by the group as being the most 
important. 
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4.6 APPLYING A SELECTION MODEL 


Investment classificatien It is not necessary to have exactly the same criteria for the different 
types of projects discussed above (strategic and operations). However, experience shows that. most 
organisations use similar criteria across all types of projects, with perhaps one or two criteria specific 
to the type of investment (e.g. strategic versus operational). Regardless of criteria differences among 
different types of investments, the most important criterion for selection is the project’s fit to the 
organisation's strategy. Therefore, this criterion should be consistent across all types of projects and 
carry a high priority, relative to other criteria. This uniformity across all priority models used can 
keep departments from sub-optimising the use of organisational resources. Anyone generating a 
project proposal should classify their proposal by type, so the appropriate criteria can be used to 
evaluate their proposal. 


Selecting a medel Inthe past, financial criteria were used almost to the exclusion of other criteria. 
However, in the last two decades we have witnessed a dramatic shift to include multiple criteria in 
project selection (this supports concepts such as triple bottom line reporting discussed elsewhere 
in this text). Concisely put, profitability alone is simply not an adequate measure of contribution; 
however, it is still an important criterion, especially for projects that enhance revenue and market 
share such as breakthrough research and development investments. 

Today, senior management is interested in identifying the potential mix of investments that will 
yield the best use of human and capital resources to maximise return on investment in the long 
run. Factors such as researching new technology, public image, ethical position, protection of the 
environment, core competencies and strategic fit might be important criteria for selecting investments. 
Weighted scoring criteria seem the best alternative to meet this need. 

Weighted scoring models result in bringing investments into closer alignment with strategic goals. 
If the scoring model is published and available to everyone in the organisation, some discipline 
and credibility are attached to the selection of investments. The number of wasteful projects using 
resources is reduced. Politics and ‘sacred cow’ projects are exposed. Project goals are more easily 
identified and communicated using the selection criteria as corroboration. Finally, using a weighted 
scoring approach helps project managers understand how their investment. (progran/project) was 
selected, how their project contributes to organisational goals and how it compares with other 
investments. Investments selection is one of the most important decisions guiding the future success 
of an organisation. Criteria for selection are the area where the power of your portfolio starts to 
manifest itself. New investments are aligned with the strategic goals of the organisation. With a clear 
method for selecting investments in place, project/program proposals can be solicited. 


4.6.1 The Business Case 


The Business Case captures all the facts, figures and reasons for the investment. It is the major source 
of program and project ‘reason for being’ as a result of the strategic and business planning processes. 
However, there must be an opportunity in the business for the submission of programs/projects from a 
bottom-up approach—for example, programs/projects identified from all levels of the organisation, 
usually by the people at the coalface of the organisation. Although these projects have been identified 
from a bottom-up approach in the organisation, they would be subject to the same investment. appraisal 
and prioritisation processes. 

In addition to top-down and bottom-up progranyproject activity, the organisation’s innovation 
processes might also generate potential project briefs for consideration. Again, as with bottom 
up identified projects, they would be subject to the same investment appraisal and prioritisation 
processes. No matter where the ‘investment’ is sourced from, many organisations use the Investment 
Business Case to research and define many aspects of the investment. The list below extends the 
(typical) Business Case table of contents that was introduced earlier in this chapter. 
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g Executive summary: Using the BLUF technique. BLUF is ‘Bottom Line Up Front’, and would 
include vital elements extracted from each of the sections discussed below—with a particular 
focus on the overall recommendations. 


Background: Describing the circumstances as to why the Business Case is being developed. 


Strategic alignment criteria: Exactly which strategic objectives does the investment align with? 
And when delivered, how much will it contribute (i.e. what is the expected impact on the KPI if 
the investment is delivered)? 


m Business opportunity: Describing the business opportunity (or problem) that is to be solved by 
the Business Case. 


m Constraints and assumptions: Items that are going to constrain the later described options, and 
assumptions-statements of truth— n regard to any aspect of the Business Case. For example, 
‘customer requires access to the building at all times during the renovation’. 


Enterprise risk assessment: Why and how the Business Case assists in changing the risk profile of 
the business in a positive manner. 


m Options analysis: Including the ‘do nothing’ and ‘deferred’ options, and usually at least three other 
options, and of course, the recommend option. 


— The ‘do nothing’ option: Outlines maintaining the status quo. Usually there is a ‘cost’ to doing this. 
There are many reasons for a cost in maintaining the status quo. These typically include increased 
maintenance costs, potential down-time to the business, loss of revenue, or loss of market segment. 

— The ‘deferred’ option: What is the case for deferring actions to a later timeframe? 

— Other options, as required: Usually a minimum of three other options would be considered. 


m@m For each of the options identified (above), analysis of: 


— Business risk: Examining how the investment stacks up against the organisational risk 
context and business risks identified through the analysis of business risk. 

— Funding analysis: Indicating how, and from where, the investment will be funded. This also 
provides details on what the estimated cost and return on the investment will be. Often 
accompanied by net present value (NPV) and/or internal rate of return (IRR) calculations, 
for each option considered. 


1. Opportunity cost: What is being given up in the way of other options, in order to pursue 
this option? This would include consideration of what the business could do with the 
money if it invested it in bonds, high-interest account(s), or other such investments. 

2. Structure/milestone summary: Indicating the approach and major components of work to 
be carried out. 

— Benefits identification and analysis: Including a benefit-cost ratio (BCR) calculation 
for each option, as each option is likely to provide a different set of benefits and will 
almost certainly cost a different. amount. 

3. Technical viability: Does the option comply with the organisation's enterprise 
architecture, technology roadmaps or blueprints? 


4. Overall recommendations: Why the recommended option has been selected over the 
other options. 


Source: @ 2018 Dr Neil Pearson 


Having this detailed level of information around each investment (progran/project) enables the 
relevant people involved in the selection and prioritisation process to make wellinformed decisions. 
Later (once approved), it will also provide the necessary background information to the prograr/ 
project manager for the project's reason for being. 
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The project manager may find that some organisations require a valid and approved Business Case 
before a project (or program) can start, and that the Business Case will become a living document 
that is carried forward with the progran/project and is reviewed at each gate. Further to this, the 
success of the project itself is not only measured against what was declared in the project scope 
document, but also any additional dimensions declared and approved in the project’s Business Case. 
Refer Figure 4.10. 


4.6.2 Ranking proposals and selection of projects 


Picking through so many proposals to identify those that add the most value requires a structured 
process. Figure 4.11 shows a generic flowchart of a screening process, beginning with the creation of a 
Business Case. Although represented as a flowchart within this text, in practice, this is often captured 
within the strategic and business planning processes of an organisation. The flowchart here represents 
the indicative steps in investment prioritisation, starting with the development of a Business Case from 
any of the three potential sources of investments: top-down from strategic planning, bottom-up from 
operational activity and those investments identified from the organisation’s innovation process. 


4.6.3 Responsibility for prioritising 

Prioritising can be a somewhat uncomfortable exercise for managers. But prioritising projects 
is a major responsibility for senior management. Prioritising means discipline, accountability, 
responsibility, constraints, reduced flexibility and loss of power. Top management commitment means 
more than giving a blessing to the priority system; it means management will have to rank and weight, 
in concrete terms, the investments (programs/projects) that best support the organisation’s objectives 
and strategies they believe to be most critical to the longterm success of the organisation. This public 
declaration of commitment can be risky if the ranked objectives later prove to be poor choices, but 
setting the course for the organisation is the accountability of top management. The good news is, 
if management is truly trying to direct the organisation to a strong future position, a good project 


priority system supports their efforts and develops a culture in which everyone is contributing to the 
goals of the organisation against a set of mutually agreed selection criteria. 
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Source: © 2018 Dr Neil Pearsen 
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External environment Internal organisational Internal organisational 
analysis analysis analysis 


Initial Business Case 
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Source: © 2018 Dr Neil Pearson 


4.7 MANAGING THE PORTFOLIO MANAGEMENT 
SYSTEM 


Managing the portfolio takes the selection system one step higher in that the merits of a particular 
investment are assessed within the context of existing investments. At the same time, it involves 
monitoring and adjusting selection and prioritisation criteria to reflect the strategic focus of the 
organisation. This requires constant management. The priority system can be managed by a small 
group of key employees in a small organisation. Or, in larger organisations, the priority system may 
be managed by the portfolio management office or may even be a part of the office of strategy 
management (OSM). 


4.7.1 Senior management input 

Management of a portfolio system requires two major inputs from senior management. First, senior 
management must provide guidance in establishing selection criteria that strongly align with the 
current organisational strategies (e.g. using the pair-wise criterion method). Second, the senior 
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management team must decide annually how to balance the available organisational resources (plant 
and equipment, people and capital) among the different types of projects. A preliminary decision 
of balance must be made by top management—for example, 20 per cent. compliance, 50 per cent 
strategic and 30 per cent operational_vefore project selection takes place, although the balance may 
be changed when the submitted projects are reviewed. Given these inputs, the priority team can carry 
out its many responsibilities, which include supporting project sponsors and representing the interests 
of the total organisation. 


4.7.2 The priority team or portfolio management office responsibilities 


It is common to find (in most medium-to-large organisations) a portfolio management office that 
will be accountable for the business planning process, the oversight of the development of the 
Investment Business Cases, and the facilitation of the prioritisation of the investment activity (with 
top management). The project portfolio office would also be a monitor and control point. involved 
in setting strategic direction and communicating with Business Case owners changes in company 
strategy to ensure continued alignment of the investment activity. The portfolio management office is 
responsible for publishing the priority of every investment and ensuring the process is open and free of 
organisational politics (the ‘he/she who shouts the loudest’ syndrome). For example, most organisations 
use scorecards to disperse the current portfolio of investments and report back on the current status 
of each, including on current issues. This open communication encourages transparency (for better or 
worse). Over time, the portfolio team evaluates the progress of the investments (programs/pro jects) 
in the portfolio. If this whole process is managed well, it can have a profound impact on the success of 
an organisation in achieving its strategic objectives. 

Constant scanning of the external environment—t o determine if organisational focus and/or 
selection criteria need to be changed—is imperative. Periodic priority reviews and changes need 
to keep current with the changing environment. Regardless of the criteria used for selection, 
each investment should be evaluated by the same criteria. If investments are classified by 
‘mandatory (compliance)’, ‘operational’ and ‘strategic’, each investment in its class should be 
evaluated by the same criteria. Enforcing the priority system is crucial. Keeping the whole system 
open (transparent) and above board is important to maintaining the integrity of the system and 
keeping new, young or even seasoned executives from going around the system. For example, 
communicating which investments are approved, investment ranks, current status of in-process 
investment, and any changes in investment criteria will discourage people from bypassing the 
system. 


4.7.3 Balancing the portfolio for risks and dependencies 


A major responsibility of the portfolio management office is to balance projects by type, risk and 
resource demand. This requires a totalorganisation perspective. Hence, a proposed investment that 
ranks high on most criteria may not be selected because the organisational portfolio already includes 
too many investments with the same characteristics_for example, risk level, use of key resources, 
high cost, non-revenue producing, and long durations. Balancing the portfolio of investment is as 
important as investment selection. Organisations need to evaluate each new investment in terms of 
what value it adds. Shor tterm needs need to be balanced with longterm potential. Resource usage 
needs to be optimised across all investments, not just the most important investment. Risks associated 
with investment need to be considered: 


1. Do the risks associated with the total portfolio of programs and projects reflect the organisation's 
risk profile? 

2. Are there specific investment risks that can inhibit the execution of a prograny/project, such as 
schedule, cost and technical? 
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In this chapter, we refer only to balancing the organisational risks inherent in the portfolio, such as 
market risk, ability to execute, time to market and technology advances. Projectspecific risks will be 


covered in detail in Chapter 17. 

Alongside the balancing of risk is the manoeuvring of 
projects, given the set of dependencies that exist among the 
group of investments at any one time. As programs and projects 
deliver, as new investments are introduced into the mix, and as 
delays and issues affect others, the dependencies will be ever 
changing and will be another factor in balancing the portfolio. 
For example, what dependencies exist between the themes 
(mandatory, strategic and operational) and the programs/projects 
in Figure 4.12? 

These ‘styles’ of dependency schedules, at a strategic level, 
are common interpretations of how the investment activity will 
be scheduledttooking at the dependency between elements on 
the schedule, and as such, any risks associated with delivering the 
portfolio in the designed manner. 

Bruce Henderson proposed BCG’s growth share matrix 
in the 1970s and the principles are still used today (usually 
captured in reports available from products such as Oracle® 
Corporation’s Primavera portfolio management tool)-refer to 
Figure 4.13. 


A company should have a portfolio of products with different 
growth rates and different market shares. The portfolio 
composition is a function of the balance between cash 
flows. . . . Margins and cash generated are a function of market 
share (Reeves, Moose & Venema 2014). 


Figure 413 BCG growth share niatrix, Boston 
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The BCG matrix is concerned with classifying product/services (investments) into the categories of: 


1. Dogs: These are investments that don’t have market share and are experiencing low market 
growth. The question is, what should be done with these investments? Does the business ‘put the 
dog down’ and ‘kill off’ the investment? 


2. Stars: These are investments that have high growth and high market share. These are the 
investments that equate to the maturity stage on the product life cycle. Businesses need to milk 
these for as long as possible and extend their life as ‘stars’. If the marketplace stays stable, these 
investments typically turn into cash cows. On some occasions, such as the introduction of the 
original iPod by Apple, if your organisation was Sony, then the Sony Walkman would immediately 
become a dog. 

3. Cash cows: These are investments that have low growth but good market share. The question is 
how long they can keep on providing revenue and at what cost to the business if market share 
potential is capped? 


4. Question marks (?): Although seeing good market growth, how does the business convert these 
investments into stars, with the added value this returns? 


Some strategies for handling these investment types are indicated in Figure 4.14. 


Figure 4.14 B 
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The result of the portfolio planning, from a project manager's perspective, could be an aligned 
structure of programs and projects that indicate the position of their particular allocated work, its 
strategic alignment and contribution to the organisation's strategy, its overall priority and other useful 
information. The project manager can use this information in multiple ways, for example to: 

1. position and understand the priority of the project 
2. build a compelling 60-second story (or elevator pitch) for the project 


3. gain understanding of the expected benefits (value) to be delivered by the project 
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4, understand upwards reporting requirements 


5. understand the dependencies between the project and other programs/projects taking place. 


Project portfolio management (PPM) can be a complex process in organisations and therefore 
PPM software is often used to assist strategists and portfolio managers. The next section reviews 
some of the features of software tools that can assist in such activities. 


4.8 PROJECT PORTFOLIO MANAGEMENT 
(PPM) SYSTEMS 


Project Management Information Systems (PMISs) are discussed at length in Chapter 16. Project 
Portfolio Management (PPM) systems have features that are not commonly found in runof-th e- 
mill PMISs. This short section aims to present some of the key features of PPM software. 


4.8.1 Features of Project Portfolio Management (PPM) systems 

As with PMISs, there is a lot of focus on cloud solutions in the software industry, and PPM is no 
different. In the Gartner cloud-based PPM magic quadrant report (Stang & Handler 2012), a number of 
trends are identified in the cloud PPM marketspace, including: 


mu The PPM sweet spot: Here, reference is made to the ‘sweet spot’ in communication and reporting. 
What level of information is captured, at what level in the organisation for effective decisions to 
be made? Using various grids and other charts to visualise information, refer to Figure 14.15. 


m PPM and Agile development. support: With the rise in the use of Agile methodologies, PPM 
applications are now supporting elements of the communication, collaboration and reporting 
nuances associated with Agile development methods. 


E Social networking and collaboration: Gartner notes that 
social networking and collaboration in the PPM context 
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full visibility into the impact to the business. Avoiding 
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low-value projects and rogue work is one of the major benefits an improved PPM process can 
deliver. 


m Better collaboration across organisational silos: If a PPM process and tool is easy to use and 
adopt, it enables teams to collaborate across organisational silos. For instance, resource 
managers and project managers can better collaborate on project staffing, and finance can more 
easily provide regular updates on project costs. This broad adoption enables real-time visibility 
into project and portfolio status, thereby allowing executives and project managers to ensure 
business results are being achieved. 


= Improved decision-making and accountability: A strong PPM solution will provide powerful 
business intelligence and reporting capabilities to enable a single source of truth for dashboards 
and reports. This enables more accurate and timely information for management decisions about 
project investments and which projects require more oversight and controls. 


E Streamlined PMO processes and templates: Implementing an overall project management 
framework, with just the basic phases and gates and a few key controlling artefacts (e.g. Business 
Case, project schedule, status report) enables a common streamlined process for the PMO, while 
also enabling individual projects to select the right methodology for their project type. 


E Improved organisational productivity: Utilising a PPM tool enables a more predictable process 
to be implemented that. eliminates unstructured data entry and management. In addition, a PPM 
solution should enable customisation to ensure the tool matches the way your organisation works. 


PPM software packages provide a basis for managing a complex mix of programs and projects 
against available resources and funding and aligning delivery (and performance) to the organisation's 
strategy. They allow the portfolio office to carry out simulations and be able to rank and prioritise, in 
order to provide that ideal ‘balanced’ set of programs and projects that the organisation is best placed 
to deliver. These systems do come with some challenges, however: 


m Process: The organisation needs to have a well-defined process for the management of 
investments—fr om conception to performance reporting. Without this, the content of the 
PPM system is likely to be a mixed bag of work. Some PPM solutions follow a particular 
project management approach, such as ISO 21500:2012, Agile, or Predictive PMI and PRINCE2 
approaches. 


m People (roles): To support the process, the organisation must define the roles of the people 
participating in the process. Who is going to maintain the mass of information in the PPM 
system ona daily basis? What committee has the approval of the portfolio? Where is the weekly/ 
monthly status of the portfolio reported to? What access do the project managers have into 
the PPM system to maintain project-related information? Remember the old adage: ‘rubbish in, 
rubbish out! 


@ Technology (integration): Integration to existing ICT systems is often critical. For example, is 
there a requirement for the PPM system to interface with the organisation's finance systems to 
capture accurate spending and funding? How does the PPM system integrate with any project 
racking systems that exist in the organisation? If your organisation leverages Microsoft Project 
Server, how is milestone and other tracking information integrated with the PPM system, so 
updates from program and project status are automatically reflected back into the portfolio 
management solution? 


m Knowledge: Is the business ready to harness the information provided by the PPM system and 
does it have the right forums, with the right people in place, to harness the collective knowledge 
of the organisation? Can this knowledge and decision-making capability be harnessed by the PPM 
system and recorded for future learning? 
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4.8.2 Prominent PPM systems 


The authors have experienced many PPM systems in their careers, from inhouse-developed 
spreadsheets offering complex solutions, to mainstream PPM systems, such as those offered by @racle 
Corporation's Primavera and Artemis™ portfolio management software. 

The choice of software systems (remember the definition of a ‘system’ here is people, process, 
technology and knowledge) is complex and a Business Case should be developed to ensure a solution 
is selected that provides the needs of the business now and in the future. 


E Alfabet (http//alfabet.softwareag.com/): Software AG's Alfabet IT Portfolio Management 


Platform. 


Artemis (www.aisc.com): Enterprise Investment, Asset, and Portfolio Management Software. 


Artemis 7 is the only enterprise system that enables realtime reporting and decision-making at 
the portfolio and investment level, based upon realtime project and resource data. 


BDaptiv (https://www.changepoint.com/products/daptiv/): Plan and monitor your portfolios, from a 


top-down perspective, to ensure you're investing in the right projects. With a realtime view across 


your enterprise, it’s easier to respond to change and confirm project objectives and trajectory to 
align with the overarching business goals of your PM®. 


SNAPSHOT FROM PRACTICE Ergon Energy 





Program JET (valued at A$35 million) involved the 
establishment of a large program of work as part of the 
business improvement portfolio of work and a strategic 
investment to replace multiple IT systems with an 
integrated Enterprise Resource Planning (ERP) system. 
The program was jointly sponsored by Ergon Energy, 
Queensland (the regional energy distributor) and Energex 
(the city and urban energy distributor). The ERP package 
was based on the Mincom Ellipse Enterprise Asset 
Management application suite. This huge program of 
work, involving more 200 employees plus contractors 
over an 18-month duration, was phased into multiple 
streams of work. 

One of the authors was jointly involved in one of 
the streams of work, to develop a future-state process 
for investment management and the configuration of 
a portfolio management system that was to support 
the process. Artemis 7 was the selected portfolio 
management solution and had to integrate with aspects 
of the ERP system and with the program/project 
management software (based on a combination of 
Artemis Views (a project management scheduling tool) 
and Microsoft Project. 

By integrating systems and having a defined workflow 
(process), the management of the many hundreds of 
Investment Business Cases and much management 
information became a routine process in the organisation. 
Previous to this, a number of ad hoc tools had been 
used to establish, prioritise and control the A$ millions of 








Pixtal/AG E Fotostock 


investment 


competing requests (some mandatory, 
based on regulatory changes, and some strategic, 
such as asset replacements and some operational 
improvements). The value of the annual portfolio for 
the building and maintenance of the assets topped the 
A$1 billion mark, so ensuring tight control of the funds 
and the investment choices was critical to business 
success and meeting the demands of the customer 
base, which was spread across a geographic area of 
1.7 million km? with 220 000 km of powerlines serving a 
population of 4.8 million. 


Sources: Mincom 2007, Ergon Energy goes live with Mincom 

Ellipse’, Business Wire, 30 May, https://www.businesswire,com/news/ 
home/20070530005988/en/Ergon-Energy | ive-Mincom-Ellipse, accessed 
February 2018 ; Woodhead B 2007, Taking care of power business’, The 
Australian Business Review, 29 May, www theaustralian.com.au/business/ 
technology/taking-care-ofpawe rusiness/news-story/23272be58 
ba896@fOae3fSd48000dc5a, accessed February 2018. 
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m PlanView (www.planview.com/itppmproject-portfoliomanagement/): By integrating planning 
and execution, Planview’s project portfolio management software enables IT leaders to optimise 
their project portfolios, balance capacity against demand, and link plans and resources to project 
execution. 


@ Primavera (https:/www.oracle.com/applications/primavera/products/projectmanagement.html): 
Primavera focuses on solutions that go beyond facilitating ontime and within budget and scope 
projects, to support business outcomes that drive C-level strategic metrics and results. 


@rganisations selecting a PPM system should consider carefully the features and complexity 
of such software packages and seek professional advice in not only their selection, but. also about 
embedding such systems within their business processes and culture. Selecting and embedding a PPM 
system is a major project in its own right. Refer to Snapshot from Practice: Ergon Energy. 


Summary 


1. This chapter has provided an introduction to the importance of strategically aligning investment activity, and prioritising 
competing investments to ensure an organisation is considerate of its external environment: 


a) time to market pressures 
b) competitive advantage 
c) legislative requirement 
d) economic conditions 
e) technology advancements. 
2. and its internal environment: 
a) limited skilled resources 
b) dispersed virtual teams 
c) corporate risk 
d) finite capital reserves. 
3. Some of the techniques that can be applied to the prioritisation of investments: 
a) analytic hierarchy process (AHP) 
b) pair-wise criterion 
c) weighted criteria 
d) nominal group technique (NGT). 


4. The contents of a Business Case, with the inclusion of both financial and non-financial criteria. The financial criteria for 
consideration would include: 


a) payback and return onthe investment 
b) net present value (NPV) and internal rate of return (IRR) 
c) benefit-cost ratio. 


We also looked at the importance of having a Business Case that starts with the investment and follows this through 
the life cycle of the program/project and remains valid throughout. 


Remember, the project manager must be able to clearly identify the strategic link of their projects, the benefits of the 
project, and the financial cost model associated with their project in order that, at the end of the project, it can be 
ascertained whether the project has delivered on the promises made within the Business Case and has delivered 
the expected value from the investment made by the organisation. 
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https://www.pmi.org/learning/library/linking-portfolio-program-projects-business-strategy-6672 
https://www.pmi.org/learning/library/linking-portfolio-program-projects-business-strategy-6895 
https://www.apm.org.uk/body-of-knowledge/p3-management/ 

www.aisc.com 

https://www.oracle.com/nl/applications/primavera/index.html 

https://decisionlens.com 
https://www.praxisframework.org/en/knowledge/project-programme-and-portfolio-management 
https://hbr.org/2008/02/close-the-gap-between-projects-1.html 

https://hbr.org/2005/ 10/the-office-of-strategy-management 
www.balancedscorecard.org/BSC-Basics/About-the-Balanced-Scorecard 
https://hbr.org/product/the-execution-premium-linking-strategy-to-operations-for-competitive-advantage/2 116-HBK-ENG 
https://www.iso.org/standard/50003.html 


analytic hierarchy process (AHP) innovation process project portfolio office (PPO) 
benefit-cost ratio (BCR) internal rate of return (IRR) Project Management Information 
Boston Consulting Group (BCG) Investment Business Case Systems (PMISs) 
matrix investments Project Portfolio Management (PPM) 
bottom-up approach mission systems 
Business Case net present value (NPV) project sponsor 
Business Case life cycle nominal group technique (NGT) SMARTA 
current state opportunity cost strategic objectives 
enterprise architecture, technology pair-wise criterion strategic planning 
roadmaps or blueprints payback model top-down approach 
future state portfolio management vision 
implementation gap priority system 


Review questions 


Describe the major components of a strategic management process. 
Explain the role projects play in the delivery of an organisation's strategy. 
Why should projects be linked to the organisation’s Strategic Plan? 


Pune 


The portfolio of projects is typically represented by compliance, strategic and operational projects. What impact can 
this classification have on project selection? 


5. Why does the priority system described in this chapter require that it be open and published? Does the process 
encourage bottom-up initiation of projects? Does it discourage some projects? Why? 


6. Why should an organisation not rely only on financial measures to select projects? 


7. Reflect on how the ‘pair-wise’ criterion system could be applied in your organisation. Against which criterion would you 
carry out prioritisation? 





8. What is the BCG matrix and how is it used? 


1. Using the BCG matrix illustrated in Figure 4.13 review the investments from the list below. 


m Investment A is a new product that has been released into the industry. It seems to be experiencing growth at this 
time. 


m Investment B has been hanging on, operations have flagged and we are not making much profit on these products. 
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m Investment C has recently seen a lot of product growth and is producing some good returns. We don’t know how long 
this will be sustained in the current environment so are watching this investment closely. 


m Investment D has slowed down in terms of growth but is still producing good returns. 

m Investment E is still seeing good returns but seems to be levelling off. We have the marketing director reviewing the 
market place to see what the trajectory is likely to do in the future. 

m Investment F is a product brought to market some months ago but the marketing director has reported that it is 
not making any progress in terms of growth or returns. 
{a) Position where you perceive the investments sit on the BCG matrix. 
{b) Further analyse these investments and determine the direction the investment could take—as illustrated in 

Figure 4.14. Justify your reasoning. 

2. In small groups, carry out research into PPM systems. Which features do you believe could be beneficial for a project 
manager in their work? 

3. Using the projects in Table 4.6, carry out an NGT session with (three) other people in your group. One person will take 
the role of facilitator, and the other three people each one of the following roles: ICT manager, managing director and 
manager of operations. The company is an IT service company that specialises in the maintenance, replacement, 
rollout and decommissioning of personal computers, laptops and mobile devices. The company, Phoenix Services, has 
been in business for three years and due to its full life cycle approach to the end user, it has gained a number of large 
local government contracts. Phoenix Services has a current workforce of 1800 fulltime employees. 

41. What were the results? 


2. How did your group compare to other groups’ prioritisation of the projects? 


Table 4.6 List of Phoenix Services projects 


Project A Implement a customer relationship management system (including business processes, systems and 
training). 

Project B Grow market share by 15% on a baseline of 33% for the organisation’s flagship service. 

Project C Develop two new services and markettest them to ensure demand for the products exists in the market 
place. 

Project D Implement social media strategies and technologies across all core services offered. 

Project E Remove one executive management position and five direct management positions to flatten the 
organisational structure in line with competitors. 

Project F Relocate toa greenfield sustainable technology park to reduce rent commitments by 30%. 

Project G Update the ERP system to the latest version, to ensure continued software support arrangements can be 
entered into. 

Project H Reduce employee headcount by 10% through implementation of efficiency programs using the Lean Six 
Sigma technique. 

Project | Outsource the payroll system and move the generation of payroll data to the human resource department. 

Project K Introduce a web-based ticket logging system based on ITIL principles for ICT, Facilities and the Human 


Resource Departments. 


4. Based on Figure 4.12, draft a dependency schedule of the programs and projects, classified under the themes of 
‘mandatory’, ‘strategic’ and ‘operational’, which you are aware of in relation to a project you are currently working on, or 
a past project. If you cannot do this make a note of the reasons why this is so, and what feedback you would now take 
back to the business. 


5. You manage a hotel resort located on a South Shore Beach on the island of Kauai in Hawaii. You are shifting the 
focus of your resort from a traditional fun-in-the-sun destination to ecotourism (eco-tourism focuses on environmental 
awareness and education). How would you classify the following projects in terms of compliance, strategic and 
operational? 


(a) Convert the pool heating system from electrical to solar power. 
(b) Construct a 6.5-km nature-hiking trail. 
(c) Renovate the equestrian facilities. 
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(d) Replace the golf shop that burned down after being struck by lightning. 
{e) Launch a new promotional campaign with Hawaii Airlines. 

(f) Convert 12 adjacent acres into a wildlife preserve. 

{g) Update all the bathrooms in condos that are 10 years old or older. 

(h) Change hotel brochures to reflect eco-tourism image. 

{i) Test and revise the resort’s disaster response plan. 

(j) Introduce wireless internet service in all areas of the resort. 


How easy was it to classify these projects? What made some projects more difficult than others? What do you think you 
now know that would be useful for managing projects at the hotel? 


6. Two new software projects are proposed to a young, start-up company. The Alpha project will cost $150 000 to 
develop and is expected to have annual net cash flow of $40 000. The Beta project will cost $200 000 to develop 
and is expected to have annual net cash flow of $50 000. The company is very concerned about their cash flow. 
Using the payback method, which project is better from a cash flow standpoint? Why? 

7. A five-year project has a projected net cash flow of $15 000, $25 000, $30 000, $20 000 and $15 000 in the 
next five years. It will cost $50 000 to implement the project. If the required rate of return is 20 per cent, conduct a 
discounted cash flow calculation to determine the NPV. 

8. You work for the 3T company, which expects to earn at least 18 per cent on its investments. You have to choose 
between two similar projects. Below is the cash information for each project. Your analysts predict that the inflation rate 
will be a stable 3 per cent over the next seven years. Which of the two projects would you fund if the decision is based 
only on financial information? Why? 

Omega Year | Inflow Outflow Netflow Alpha Year Inflow Outflow | Netflow 

YO ie} $225 000 -225 000 YO (0) $300 000 -300 000 

val 0 190 000 —190 000 Y1 $ 50 000 100 000 -50 000 

Y2 $ 150 000 0 150 000 Y2 150 000 0 150 000 

v2 220 000 30 000 190 000 ve 250 000 50 000 200 000 

Y4 215 000 Oo 215 000 Y4 250 000 Oo 250 000 

YS 20 000 30 000 175 000 y5 200 000 50 000 150 000 

Y6 197 000 0 197 000 Y6 180 000 Oo 180 000 

Y7 100 000 30 000 70 000 Vee! 120 000 30 000 90 000 

Total 1 087 000 50 000 582 000 Total 1 200 000 530 000 670 000 

9. You are the head of the project selection team at SIMSOX. Your team is considering three different projects. Based on 
past history, SIMSOX expects at least a rate of return of 20 per cent. Your financial advisers predict inflation to remain 
at 3 per cent into the foreseeable future. 

Given the following information for each project, which one should be SIMSOX’s first priority? Should SIMSOX fund any 
of the other projects? If so, what should be the order of priority based on return on investment? 
Project: Dust Devils 
Year Investment Revenue stream 
[0] $500 000 Oo 
1 50 000 
2 250 000 
3 350 000 
10. You are the head of the project selection team at Broken Arrow Records. Your team is considering three different 


recording projects. Based on past history, Broken Arrow expects at least a rate of return of 20 per cent. Your financial 
advisers predict inflation to remain at 2 per cent into the foreseeable future. 
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Given the following information for each project, which one should be Broken Arrow’s first priority? Should Broken 
Arrow fund any of the other projects? If so, what should be the order of priority based on return on investment? 


Recording Project: Time Fades Away 


Year Investment Revenue stream 
0 $600 000 0 
1 600 000 
2 75 000 
3 20 000 
4 15 000 
5 10 000 


Project: Ospry 


Year Investment Revenue stream 
[0] $250 000 0 
1 75 000 
2 75 000 
3 75 000 
4 50000 


Project: Voyagers 


Year Investment Revenue stream 
0 $75 000 0 
1 15 000 
2 25 000 
Bi 50000 
4 50000 
5 150 000 


Recording Project: On the Beach 


Year Investment Revenue stream 
0 $400 000 0 
1 400 000 
2 100 000 
3 25 000 
4 20000 
5 10 000 
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Recording Project: Tonight’s the Night 


Year Investment Revenue stream 


ie} $200 000 ie} 
1 200 000 
2 125 000 
3 75 000 
4 20 000 
5 10 000 


11. The Custom Bike Company has set up a weighted scoring matrix for evaluation of potential projects. Below are three 
projects under consideration. 
{a) Using the scoring matrix in Figure 4.16, which project would you rate highest? Lowest? 


{b) If the weight for ‘Strong sponsor’ is changed from 2.0 to 5.0, will the project selection change? What are the three 
highest weighted project scores with this new weight? 


{c) Why is it important that the weights mirror critical strategic factors? 


Figure 4.46 Project screening matrix 
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Additional exercises, selected solutions and an additional case study, Hector Gaming Company, are 
available online. 
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CHAPTER 5 


PROJECT ORGANISATIONAL 
STRUCTURES AND CULTURES 


Learning elements | 

















5A Understand the different project organisational structures that broadly define 
how the project fits with the organisational structures that may already exist in an 
organisation. 

SB Further understand the types and features of the different levels of project 
management office (PMO). 

5C Realise the importance of an organisation’s culture and the effect it can have on the 
management of a project. 

5D Beable to identify and incorporate cultural considerations across continents, | 
countries and companies. | 

\ 
In this chapter 


5.1 Introduction 


| 


E E EEE E 


] 


5.2 Project management structures 

5.3 What is the right project management structure? 

5.4 Further discussion on the project management office 

5.5 Organisational culture 

5.6 Implications of organisational culture when organising projects 
5.7 Working across international cultures 

5.8 Scrum/Agile considerations 
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5.1 INTRODUCTION 


The previous chapter looked at the strategic alignment of investments (portfolios, programs and 
projects), and the prioritisation of programs and projects within a portfolio. The chapter closed with a 
resulting list of approved programs and projects to be delivered by the accountable business managers 
(sponsors). The question this chapter seeks to answer is: ‘What project structures and organisational 
cultures does the project manager have options to operate within?’ This chapter examines three 
different project management structures used by firms to implement projects. 

These structures typically overlay the organisational structures already in place and are referred 
to in project management terminology as the ‘functional organisational structure’, the ‘dedicated 
project team structure’, and the ‘three types of matrix structures’. Although not exhaustive, 
these structures and their variant forms represent the major approaches for organising projects in 
organisations. The advantages and disadvantages of each of these structures are discussed as well as 
some of the critical factors that might lead an organisation to choose one form over the others. 

Whether an organisation chooses to complete projects within the traditional functional organisation 
or through some form of matrix arrangement is only part of the story. Anyone who has worked for 
more than one organisation no doubt realises there are often considerable differences in how projects 
are managed within certain organisations with similar structures. For example, working in a matrix 
system at AT&T (an American telecommunications conglomerate) is different from working in a 
matrix environment at the Australian Bureau of Statistics (an Australian government department). 
Many researchers attribute these differences to the organisational ‘culture’—a simple explanation of 
organisational culture is that it reflects the ‘personality’ of an organisation. Just as each individual has 
a unique personality, so each organisation has a unique culture. Towards the end of this chapter, we 
will examine in more detail what organisational culture is, and the impact the culture of the parent 
organisation has on organising and managing projects. 

Both the project management structure and the culture of the organisation constitute major 
elements of the environment in which projects are implemented. It is important for project managers 
and participants to know the ‘lay of the land’ so they can avoid obstacles and take advantage of 
pathways to complete their projects. 
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Although the culture within which the project occurs is not formally documented, the project 
organisational structure is documented within the scope document and/or the Human Resource 
Management Plan; thus providing a clear indication of how the project team is structured. The project 
organisational chart will also outline the interactions, in terms of resources committed and governance 
committees (such as a Change Control Board (CCB) and/or PMO). 


5.2 PROJECT MANAGEMENT STRUCTURES 


A project management system provides a framework for launching and implementing project activities 
within a parent organisation. A good system appropriately balances the needs of both the parent 
organisation and the project, by defining the interface between the project and parent organisation 
in terms of authority, allocation of resources and eventual integration of project outcomes into 
mainstream operations. 

Many business organisations have struggled with creating a system for organising projects while 
managing ongoing operations. One of the major reasons for this struggle is that projects contradict 
fundamental design principles associated with traditional organisations. Projects are unique, one- 
time efforts, with a distinct beginning and end. Most organisations are designed to efficiently manage 
ongoing activities. Efficiency is achieved primarily by breaking down complex tasks into simplified, 
repetitive processes, as symbolised by information technology (IT) service management. Projects are 
not routine and therefore can be ‘like ducks out. of water’ in these work environments. With this in 
mind, we will start the discussion of project management structures. 


5.2.1 Organising projects within the functional organisation 

One approach to organising projects is to simply manage them within the existing functional hierarchy 
of the organisation. Once management decides to implement a project, the different segments of the 
project are delegated to the respective functional units with each unit responsible for completing its 
segment of the project (Figure 5.1). Coordination is maintained through normal line management 
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channels. For example, a tool manufacturing firm decides to differentiate its product line by offering 
a series of tools specially designed for left-handed individuals. Top management decides to implement 
the project, and different segments of the project are distributed to appropriate areas. The industrial 
design department is responsible for modifying specifications to conform to the needs of left-handed 
users. The production department is responsible for devising the means for producing new tools 
according to these new design specifications. The marketing department is responsible for gauging 
demand and price as well as identifying distribution outlets. The overall project will be managed 
within the normal hierarchy, with the project being part of the working agenda of top management. 

The functional organisation is also commonly used when, given the nature of the project, one 
functional area plays a dominant role in completing the project or has a dominant interest in the 
success of the project. Under these circumstances, a senior manager in that area is given the 
responsibility of coordinating the project. For example, the transfer of equipment and personnel to 
a new office would be managed by a senior manager in the firm's facilities department. Likewise, a 
project involving the upgrading of the Management Information System (MIS) would be managed by 
the information systems department. In both cases, most of the project work would be done within 
the specified department and coordination with other departments would occur through normal 
channels. 

There are advantages and disadvantages in using the existing functional organisation to administer 
and complete projects. The major advantages include the following. 


1. No change to the existing functional organisational structure: Projects are completed within the 
basic functional structure of the organisation. There is no radical alteration in the design and 
operation of the organisation to facilitate the delivery of the project. 


2. Flexibility: There is maximum flexibility in the use of staff. Appropriate specialists in different 
functional units can temporarily be assigned to work on the project and then returned to 
their normal work. With a broad base of technical personnel available within each functional 
department, people can be switched among different projects with relative ease. 


3. In-depth expertise: If the scope of the project is narrow and the proper functional unit is assigned 
primary responsibility, then in-depth expertise can be brought to bear on the most crucial aspects 
of the project. 

4. Easy post-project transition: Normal career paths within a functional division are maintained. 
While specialists can make significant contributions to projects, their functional field is their 
professional home and the focus of their professional growth and advancement. 


Just as there are advantages for organising projects within the existing functional organisation, 
there are also disadvantages. These disadvantages are particularly pronounced when the scope of 
the project is broad and one functional department does not take the dominant technological and 
managerial lead on the project. 


1. Lack of focus: Each functional unit has its own core routine work to do; sometimes project 
responsibilities get pushed aside to meet primary operational obligations. This difficulty is 
compounded when the project has different priorities for different units. For example, the 
marketing department may consider the project as urgent while the operations people considered 
it only of secondary importance. Imagine the tension if the marketing people have to wait for the 
operations people to complete their segment of the project before they proceed. 

2. Poor integration: There may be poor integration across functional units. Functional specialists 
tend to be concerned only with their segment of the project and not with what is best for the total 
project. 

3. Slow: It generally takes longer to complete projects through this functional arrangement. 


This is in part attributable to slow response time; project information and decisions have to 
be circulated through normal management channels. Furthermore, the lack of horizontal, 
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direct communication among functional groups contributes to rework as specialists realise the 
implications of others’ actions after the fact. 


4. Lack of ownership: The motivation of people assigned to the project can be weak. The project 
may be seen as an additional burden that is not directly linked to their professional development 
or advancement. Furthermore, because they are working on only a segment of the project, 
professionals do not identify with the project. Lack of ownership discourages strong commitment. 
to projectrelated activities. 


5.2.2 Organising projects as dedicated teams 


At the other end of the structural spectrum is the creation of dedicated project teams. These teams 
operate as separate units from the rest of the parent organisation. Usually a full-time project manager 
is designated to pull together a core group of specialists who work full time on the project. The 
project manager recruits necessary personnel from both within and outside the parent. company. 
The subsequent team is physically separated from the parent organisation and given a mandate to 
complete the project (Figure 5.2). The interface between the parent organisation and the project teams 
will vary. In some cases, the parent organisation maintains a tight rein through financial controls. In 
other cases, firms grant the project manager maximum freedom to get the project done as they see fit. 

In the case of firms where projects are the dominant form of business (such as a construction firm 
or a consulting firm), the entire organisation is designed to support project teams. Instead of one or 
two special projects, the organisation consists of sets of quasi-independent teams working on specific 
projects. The main responsibility of traditional functional departments is to assist and support these 
project teams. For example, the marketing department is directed at generating new business that will 
lead to more projects, while the human resource department is responsible for managing a variety 
of personnel issues as well as recruiting and training new employees. This type of organisation is 
referred to in the project management literature as a projectised organisation (Figure 5.3). It is 
important to note that not all projects are dedicated project teams; personnel can work parttime on 
several projects. 
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Figure 5.3 Prc nal structure 
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As in the case of a functional organisation, a ‘dedicated project team approach’ has its strengths 
and weaknesses. For example, the fellowing are recognised as strengths. 


1. Simple: Other than taking away resources— n the form of specialists assigned to the projectthe 
functional organisation remains intact, with the project team operating independently. 


2. Fast: Projects tend to get done more quickly when participants devote their full attention to the 
project and are not distracted by other obligations and duties. Furthermore, response time tends 
to be quicker under this arrangement because most decisions are made within the team and are 
not deferred up the hierarchy. 


3. Cohesive: A high level of motivation and cohesiveness often emerges within the project team. 
Participants share a common goal and personal responsibility toward the project and the team. 


4. Cross-functional integration: Specialists from different areas work together closely and, with proper 
guidance, become committed to optimising the project, not their respective areas of expertise. 


In many cases, the project team approach is the optimum approach for completing a project when 
you view it solely from the standpoint of what is best for completing the project. Its weaknesses 
become more evident when the needs of the parent organisation are taken into account. 


1. Expensive: Not only have you created a new management position (project manager), but 
resources are also assigned ona fulltime basis. This can result in duplication of efforts across 
projects and a loss of economies of scale. 


2. Internal strife: Sometimes dedicated project teams take on an entity of their own and a disease 
known as projectitis develops. A strong ‘we-they’ divisiveness emerges between the project 
team and the parent organisation. This divisiveness can undermine not only the integration of the 
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eventual outcomes of the project into mainstream operations, but also the assimilation of project 
team members back into their functional units once the project is completed. 


3. Limited technolegical expertise: Creating self-contained teams inhibits maximum technological 
expertise being brought to bear on problems. Technical expertise is limited somewhat to 
the talents and experience of the specialists assigned to the project. While nothing prevents 
specialists from consulting with others in the functional division, the ‘we-they’ syndrome, and 
the fact that such help is not formally sanctioned by the organisation, discourages this from 
happening. 

4. Difficult pestpre ject transition: Assigning full-time personnel to a project creates the dilemma 
of what to do with personnel after the project is completed. If other project work is not available, 
then the transition back to their original functional departments may be difficult because of 
their prolonged absence and the need to catch up with recent developments in their functional 
area. For example, an employee may be ‘seconded’ to a project from the business. The seconded 
person’s role may have been backfilled with a temporary employee; when the seconded person is 
returned to the business, careful planning with HR would be required in order that the temporary 
employee is released before the ‘seconded’ person is able to return to their substantive position 
within the business. 


5.2.3 Organising projects within a matrix arrangement 


Matrix management is a hybrid organisational form in which a horizontal project management 
structure is ‘overlaid’ on top of the normal functional hierarchy. In a matrix system, there are usually 
two chains of command: one along functional lines (reporting to the line manager) and the other 
along project lines (reporting to the project manager). Instead of delegating segments of a project to 
different units or creating an autonomous team, project participants report simultaneously to both 
functional and project managers. 

Companies apply this matrix arrangement in a variety of different ways. Some organisations set 
up temporary matrix systems to deal with specific projects, while the ‘matrix’ structure may be a 
permanent fixture in other organisations. Let us first look at its general application and then proceed 
to a more detailed discussion of its finer points. Consider Figure 5.4. There are three projects currently 
underway: A, B and C. All three projects have a dedicated project manager reporting to the director 
of project management, who supervises all projects. Each project has an administrative assistant, 
although the one for project C is only part time. 


E Project A involves the design and expansion of an existing production line to accommodate 
new metal alloys. To accomplish this objective, Project A has assigned to it: 4.5 people from 
manufacturing and 6 people from engineering. These individuals are assigned to the project on a 
parttime or full-time basis, depending on the project’s needs during various stages of the project. 


E Project B involves the development of a new product that requires the heavy representation of 
engineering, manufacturing and marketing. 


E Project C involves forecasting the changing needs of an existing customer base. 


While these three projects (as well as others) are being completed, the functional divisions continue 
performing their basic, core activities. 

The matrix structure is designed to optimally utilise resources by having individuals work on 
multiple projects as well as being capable of performing/conducting normal functional (operational) 
business as usual (BaU) duties. At the same time, the matrix approach attempts to achieve greater 
integration by creating and legitimising the authority of a project manager. In theory, the matrix 
approach provides a dual focus between functional/technical expertise and project requirements 
that is missing in either the dedicated project team or functional approach to project management, as 
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Figure 5.4 
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outlined previously. This focus can most easily be seen in the relative input of functional managers 
and project managers over key project decisions (Table 5.1). 


Table 5.1 Division of project manager and functional manager responsibilities in a 
matrix structure 


Project manager Negotiated issues Functional manager 


What has to be done? Who will do the task? How will it be done? 

When should the task be done? Where will the task be done? How will the project involvement 
impact normal functional activities? 

How much money is available to Why will the task be done? How well has the functional input 

do the task? been integrated? 

How well has the total project Is the task satisfactorily Can | gain the benefits promised? 

been done? completed? 


5.2.4 Different matrix forms 


In practice there are three key kinds of matrix systems, depending on the relative authority of the 
project and functional managers. The following is an outline of the three kinds of matrix forms: 


1. Weak matrix: This form is very similar to a functional approach, with the exception that there is 
a formally designated project manager responsible for coordinating project activities. Functional 
managers are responsible for managing their segment of the project. The project manager acts as 
a staff assistant who draws the schedules and checklists, collects information on status of work 
and facilitates project completion. The project manager has indirect authority to expedite and 
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Figure 5.4 (Continued) 
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monitor the project. Functional managers call most of the shots and decide who does what and 
when the work is completed. 


Balanced matrix: This is the classic matrix in which the project manager is responsible for 
defining what needs to be accomplished, while the functional managers are concerned with hew 
it will be accomplished. More specifically, the project manager establishes the overall plan for 
completing the project, integrates the contribution of the different disciplines, sets schedules 

and monitors progress. The functional managers are responsible for assigning personnel and 
executing their segment of the project according to the standards and schedules set by the project 
manager. The merger of ‘what and how’ requires both parties to work closely together and jointly 
approve technical and operational decisions. 


Streng matrix: This form attempts to create the ‘feel’ of a project team within a matrix 
environment. The project manager controls most aspects of the project, including scope trade- 
offs and assignment of functional personnel. The project manager controls when and what 
specialists do and has final say on major project decisions. The functional manager has title over 
‘their people’ and is consulted on as-needed basis. In some situations, a functional manager's 
department may serve as a ‘subcontractor’ for the project, in which case they have more control 
over specialised work. For example, the development of a new series of laptop computers may 
require a team of experts from different disciplines working on the basic design and performance 
requirements within a Project Matrix arrangement. Once the specifications have been determined, 
the final design and production of certain components (e.g. a power source) may be assigned to 
respective functional groups to complete. 
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Matrix management—both in general and in its specific forms—has unique strengths and 
weaknesses. The advantages and disadvantages of matrix organisations in general are noted below 
(only briefly highlighting specifics concerning different forms): 


m Efficient: Resources can be shared across multiple projects as well as within functional divisions. 
Individuals can divide their energy across multiple projects on an as-needed basis. This reduces 
duplication required in a projectised structure. 


E Streng preject fecus: A stronger project focus is provided by having a formally designated project. 
manager who is responsible for coordinating and integrating the contributions of different units. This 
helps sustain a holistic approach to problem-solving that is often missing in the functional organisation. 


E Easier pest-preject transitien: Because the project organisation is overlaid on the functional 
divisions, specialists maintain ties with their functional group, so they have a substantive role to 
return to once the project is complete. 


m Flexible: Matrix arrangements provide for flexible utilisation of resources and expertise within 
the firm. In some cases, functional units may provide individuals who are managed by the project 
manager. In other cases, the functional manager monitors the contributions. 


The strengths of the matrix structure are considerable. Unfortunately, so are the potential weaknesses. 
This is due in large part to the fact that a matrix structure is more complicated and the creation of multiple 
bosses represents a radical departure from the traditional hierarchical authority system. 

Furthermore, one does not install a matrix structure overnight. Experts argue that it takes three 
to five years for a matrix system to fully mature. So, many of the problems described below represent 
growing pains. 


E Dysfunctienal cenflict: The matrix approach is predicated on tension between functional 
managers and project managers who bring critical expertise and perspectives to the project. 
Such tension is viewed as a necessary mechanism for achieving an appropriate balance between 
complex technical issues and unique project requirements. While the intent is noble, the effect 
is sometimes analogous to opening Pandora’s box. Legitimate conflict can spill over to a more 
personal level, resulting from conflicting agendas and accountabilities. Worthy discussions can 
degenerate into heated arguments that engender animosity among the managers involved. 


m Infighting: Any situation in which equipment, resources and people are being shared across projects 
and functional activities lends itself to conflict and competition for scarce resources. Infighting can 
occur among project managers, who are primarily interested in what is best for their project. 


E Stressful: Matrix management violates the management principle of unity of command. Project 
participants have at least two bosses—their functional manager and one or more project 
managers. Working in a matrix environment can be extremely stressful. Imagine what it would 
be like to work in an environment in which you are being told to do three potentially conflicting 
things by three different managers. 


E Slew: In theory, the presence of a project manager to coordinate the project should accelerate the 
completion of the project. In practice, decision-making can get bogged down as agreements have 
to be forged across multiple functional groups. This is especially true for the balanced matrix. 


When the three variant forms of the matrix approach are considered, we can see that advantages 
and disadvantages are not necessarily true for all three forms of matrix. The strong matrix is likely 
to enhance project integration, diminish internal power struggles and ultimately improve control of 
project activities and costs. On the downside, technical quality may suffer because functional areas 
have less control over their contributions. Finally, projectitis may emerge as the members develop a 
strong team identity. 
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The weak matrix is likely to improve technical quality as well as provide a better system for 
managing conflict across projects because the functional manager assigns personnel to different 
projects. The problem is that functional control is often maintained at the expense of poor project 
integration. The balanced matrix can achieve better balance between technical and project 
requirements, but it is a very delicate system to manage and is more likely to succumb to many of the 
problems associated with the matrix approach. 


5.3 WHAT IS THE RIGHT PROJECT MANAGEMENT 
STRUCTURE? 


There is growing empirical evidence that project success is directly linked to the amount of autonomy 
and authority project managers have over their projects. However, most of this research is based 
on what is best for managing specific projects. It is important to remember what was stated in the 
beginning of the chapter—that the best system balances the needs of the project with those of the 
parent organisation. So what project structure should an organisation use? This is a complicated 
question with no precise answers and a number of issues need to be considered at both the organisation 
and project level. 


5.3.1 Organisational considerations 


At the organisation level, the first question that needs to be asked is: ‘How important is project 
management to the success of the firm?’ What percentage of core work involves projects? If over 
75 per cent of work involves projects, then an organisation should consider a fully projectised 
organisation. If an organisation has both operations and projects, then a matrix arrangement would 
appear to be appropriate. If an organisation has very few projects, then a less formal arrangement 
is probably all that is required. Dedicated teams could be created on an as-needed basis and the 
organisation could outsource project work. 

A second key question is resource availability. Remember, the matrix structure evolved out of the 
necessity to share resources across multiple projects and functional domains while at the same time 
creating legitimate project leadership. For organisations that cannot afford to tie up critical personnel 
on individual projects, a matrix system would appear to be appropriate. An alternative would be to 
create a dedicated team but outsource project work when resources are not available internally. 

Within the context of the first two questions, an organisation needs to assess current practices and 
what changes are needed to more effectively manage projects. A strong Project Matrix is not installed 
ovemight. The shift towards a greater emphasis on projects has a host of political implications that 
need to be worked through, requiring time and strong leadership. For example, we have observed 
many companies that make the transition from a functional organisation to a matrix organisation 
begin with a weak functional matrix. This is due in part to resistance by functional and department 
managers towards transferring authority to project managers. With time, these matrix structures 
eventually evolve into a Project Matrix. Many organisations have created project management offices 
(PMOs) (as introduced in Chapter 2) to support project management efforts. See Snapshot from 
Practice: Project management offices. 


5.3.2 Project considerations 

At the project level, the question is: How much autonomy does the project need in order to be 
successfully completed? Hobbs and Ménard (1993) identified seven factors that. should influence the 
choice of project management structure: 

1. size of project 


2. strategic importance 
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SNAPSHOT FROM PRACTICE Project management offices 





Project management offices (PMOs) were originally — How are we @oing in terms of cost? Which projects 
developed as a response to the poor track record are over or under budget? 

many companies had in completing projects on time, — What are the major problems confronting projects? 
within budget, and according to plan. They were often Are contingency plans in place? What can the 
established to help matrix systems mature into more organisation do to help the project? 


effective project delivery platforms. 

Today, PMOs come in many different shapes and forms. 
One interesting way of classifying PMOs was set forth by 
Casey and Peck (2001), who describe certain PMOs in 
terms of being: (1) a weather station, (2) a control tower or 
(3) a resource pool. Each of these models performs a very 
different function for its organisation. 


m A control tower: The primary function of the control 
tower PMO is to improve project execution. It 
considers project management as a profession to be 
protected and advanced. The PMO identifies best 
practices and standards for project management 
excellence. They work as consultants and trainers to 
support project managers and their teams. 

m A weather station: The primary function of the 
weather station PMO is to track and monitor project 
performance. It is typically created to satisfy top 
management's need to stay on top of the portfolio 
of programs and projects underway in the firm. 
Staff provide an independent forecast of project 
performance. The questions answered for specific 
projects include: 


m A resource pool: The goal of the resource pool PMO 
is to provide the organisation with a cadre of trained 
project managers and professionals. It operates like an 
academy for continually upgrading the skills of a firm’s 
project professionals. In addition to training, this kind 
of PMO also serves to elevate the stature of project 
management within the organisation. 
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The higher the levels of these seven factors, the more autonomy and authority the project 
manager and project team need in order to be successful. This translates into using either a 
dedicated project team or a Project Matrix structure. For example, these structures should be used 
for large projects that are strategically critical and are new to the company, thus requiring much 
innovation. These structures would also be appropriate for complex, multidisciplinary projects 
that require input from many departments, as well as for projects that require constant contact 
with customers to assess their expectations. Dedicated project teams should also be used for 
urgent projects in which the nature of the work requires people working steadily from beginning 
to end. 

Many of the firms who are heavily involved in project management create a flexible management 
system to organise projects according to project requirements. Advanced development projects 
are highrisk endeavours involving the creation of a breakthrough product or process. Platform 
projects are mediumzisk projects involving system upgrades that yield new products and processes. 
Incremental projects are low-risk, shortterm projects that involve minor adjustments in existing 
products and processes. 
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At any point in time, a medium-sized organisation might have 40-50 projects underway, of which 
only one or two are advanced, three to five are platform projects and the remainder are small, 
incremental projects. The incremental projects are almost all done within a weak matrix with the 
project manager coordinating the work of functional subgroups. A strong matrix is used to complete 
the platform projects, while dedicated project teams are typically created to complete the advanced 
development projects. More and more companies are using this ‘mix-and-match’ approach to managing 
projects. 


5.4 FURTHER DISCUSSION ON THE PROJECT 
MANAGEMENT OFFICE 


So far, we have touched on how PMOs are considered to be part of a project’s organisational structure. 
This section defines the different types of PMO and also takes a look at some of their respective 
functions. To help unpack some of the types of PMO that could occur at different levels of a project 
organisation’s structure, refer to Figure 5.5. 

At the most strategic point in the organisation there could be (what we have termed here) the 
Office of Strategy Management (OSM): this is where strategy is designed (architected), developed, 
planned, aligned, reviewed, communicated, cascaded and adapted. The PMO ‘reports’ into the 
OSM and provides status updates on how the portfolios are delivering on the organisation’s 
strategy. 


E Level 1, portfolio management office (Portfolio-MO): Besides reporting progress towards the 
strategic objectives (as outline above), the Portfolio-MO (among its many functions) designs, 
develops, plans and reviews the portfolios of strategic and operational work and ensures 
aggregated information is available to the senior management teams. 
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E Level 2, the program management office (Program-MO) may be established to manage a 
single program of work (such as an accident and emergency ward refit) or may be established 
to support multiple programs of work. Either way, its primary concerns are providing direct 
support and program(s) reporting. 


= Level 3, the project management office (Project-MO) is usually established on the same 
principle as the Program-MO, but it is focused specifically on the project delivery level of an 
organisation. 


Some common themes can be found across all the levels (1, 2, or 3) and a management office 
(MO) may focus on one or more of the levels. The Project Management Institute (PMI) terms these 
supportive, controlling and directing. A particular MO (e.g. a Program-MO or Project-MO) might 
provide the features of all three or might focus on the controlling theme. From initial discussions, the 
project manager should be able to quickly identify whether the PMO is: 


= Supportive PMOs guide the projects within their remit, often providing project management 
guidelines, templates and training to support a consistent delivery of projects. They will often 
offer registers of lessons-learned for project managers to review and inform current projects so 
that ‘negative’ lessons are not repeated and ‘positive’ lessons are leveraged. Their role is guiding 
and they often do not have high levels of control. 


= Controlling PMOs introduce gate reviews with must-do activities that projects must satisfy in 
order to progress through the life cycle (e.g. project managers must ensure that the Business Case 
remains valid and is updated with current findings to ensure the project will deliver the intended 
benefits (financial or other) that were originally stated). Controlling PMOs may also introduce a 
standard change request process and Change Control Board to approve changes before the project 
manager can commit to them in the project. 


m Directive PMOs take controlling a step further by taking a vested interest in the progress of the 
project throughout its entire life cycle. Project managers are assigned to the project by the PMO 
and report directly to the PMO. 


The upshot of this is that when you (as a project manager) ask whether a PMO exists, you can be 
more specific, as this will influence how you leverage the PMO in the project’s organisational structure 
and will help you to leverage what. expectations are set. 

A‘PMO' can, and does, mean different things to different people depending on what the purpose 
of the PMO was set up to achieve. Table 5.2 tabulates supportive, controlling and directive features 
against portfolio, program and project. 

Referring to Table 5.2, the project manager should be able to identify: 


Æ which of the level(s) of management office exists (portfolio, program and/or project) 


=m the predominant, or mix, of ‘themes’ the management office uses in its approach. If, for example, 
the project management office is geared towards the supportive theme, does the project manager 
have more flexibility in the project management approach they can select? 


Em the key features offered by the management office, and the degree of optionality or compliance 
the project manager has. 


Note on terminology: The reader may also see the terms ‘PM3’ (portfolio management, program 
management, project management) or ‘P3M’ (portfolio, program and project management) used. 
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Table 5.2 Portfolio, program and project: Supportive, controlling and directive features 


Management | Portfolio 





Supportive 


Controlling 


Directive 


Forecasting supply and demand 
(e.g. of resources) at the portfolio 
level. 

Maintaining and promoting the 
shared use of a portfolio-level 
Lessons-Learned Register. 


Forecasting supply and demand 
for a portfolio that can be 
further broken down into supply 
and demand for projects and 
programs. 

Aggregating and providing 
performance results of the 
portfolio, most likely reporting 
to the Office of Strategy 
Management (OSM) or executive 
management team. 

Identifying risks, analysing risks 
and planning risk responses at a 
portfolio level. 


Establishing the portfolio 
Management methodology, best 
practices and standards for use 
as guidelines, while formulating 
the methodology and standards 
for project and program 
management. 

Defining a portfolio management 
strategy. 

Providing portfolio oversight and 
managing the overall portfolio 
value, to ensure the delivery of 
the organisation’s strategy, and/ 
or business plans. 


Program 


m Program Management Information 


Systems and repositories. 


m Program management information 


and knowledge management, and 
the transfer of information between 
programs. 


m Program management education 


and training in the governance and 
procedures to be adopted. 


m Maintaining and promoting the 


shared use of a program-level 
Lessons-Learned (Retrospective) 
Register. 


m Providing pooled organisational 


change management resources to 
the program. 


m Coaching, mentoring, training and 


oversight. 


m Providing aggregated reporting 


across the program to the program 
Managers and the portfolio 
Management office. 


m Identifying risks, analysing risks 


and planning risk responses ata 
program level. 


m Program management audits 


(including advisory health checks). 


m Terminating projects and, ultimately, 


the program. 


m Managing shared resource pools 


across the program. 


m Maintaining a records library of all 


program and project artefacts. 


m Maintaining a master program 


schedule, tracking dependencies 
between projects in/across the 
program down to an individual task/ 
activity level. 


m Identifying and developing program 


Management methodology, best 
practices and standards. 


m Developing and managing program 


policies, procedures, templates and 
other shared artefacts. 


m Establishing required committees, 


including the Change Control Board 
(CCB). 





Leading information and knowledge 
transfer between projects in the 
program for tacit and explicit 
knowledge and information. 
Coaching, mentoring, training and 
oversight. 

Coordinating communication across 
projects as required. 

Maintaining and promoting the 
shared use of a cross-project 
Lessons-Learned Register. 
Providing pooled organisational 
change management resources to 
projects being administered by the 
PMO. 

Establishing project manager 
communities of practice (CoP) or 
other sharing mediums across 
projects. 


Terminating projects. 

Providing aggregated reporting 
across all projects administered by 
the PMO, to the project managers 
and also to the PMO. 

Identifying risks, analysing risks, and 
planning risk responses across all 
projects administered by the PMO. 
Managing shared resource pools 
across all projects administered by 
the PMO. 

Monitoring compliance with project 
management standards, policies, 
procedures, and templates by 
means of project audits (often 
referred to as project health 
checks). 

Maintaining a records library of 

all project artefacts, to ensure 
reinvention of the proverbial wheel 
does not waste resources on future 
projects. 


Identifying and developing the 
project management methodology, 
best practices and standards. 
Developing and managing project 
policies, procedures, templates and 
other shared documentation. 
Defining roles and responsibilities, 
defining a project-level RASCI {see 
Chapter 14). 

Establishing required committees, 
including the CCB. 


Source: Adapted and extended from: The Standard for Portfolio Management, p. 18, 3rd edn., PMI 2013; The Standard for Program Management, p. 64, 3rd edn., 
PMI 2013; A Guide to the Project Management Body of Knowledge, p. 49, PMI 2017 
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5.5 ORGANISATIONAL CULTURE 


So how does organisational culture affect the selection of which project organisation to apply? 
Let's look at two organisations: one is a long-established government department and the other is a 
commercial organisation that prides itself on the ability to get products to market quickly. 

In the first organisation (a long-established government organisation), people are tasked to both 
operational day-to-day activities (on tightly defined employment contracts under the auspice of an 
enterprise bargaining agreement) and also, for a percentage of their time, to projects. As the projects 
cannot be organised (or funded) with dedicated project personnel, the project managers and the 
employees resourced to the projects come from across the business and a weak matrix organisational 
structure takes shape. The managers, who are also the project managers, closely manage the workload 
of the employees to ensure that both the operational day-to-day activities are carried out as well as 
tasks allocated to the employees in respect to delivering the projects. The arrangement works well 
as the department has no pressures upon it to bring products to market (although projects do have to 
be completed to the agreed schedule), so the daily customerfacing activities can be met. 

The commercial organisation has great success in using dedicated project teams, is resourced to 
carry out. all aspects of the project, and reports to a fulltime project manager who is fully engaged 
to deliver the project in the most efficient manner possible. The support functions within the business 
provide services to the project, such as human resource and procurement services. The culture of 
the organisation is to rotate project resources around the projects and to give the project employees 
a choice of which projects to participate in. This works well for the organisation, as there are more 
projects in the pipeline than there are people to carry out the projects. The project employees get to 
choose the subject nature of the project they wish to be involved in (as opposed to being allocated on 
a prearranged basis) and the organisation, in most cases, fills the project roles with employees who 
are interested and passionate about the project. 

Gaining efficiencies in the ‘marriage’ between the organisation’s culture, and the organisational 
structure and project’s structure, is often a learning exercise and one structure (solution) may not 
fit all projects. Smaller projects could be delivered within a weak matrix structure; however, larger 
complex projects often require dedicated project structures. 


5.5.1 What is organisational culture? 


Organisational culture refers to a system of shared norms, beliefs, values and assumptions that 
bind people together, thereby creating shared meanings. This system is manifested by customs and 
habits that exemplify the values and beliefs of the organisation. For example, egalitarianism may 
be expressed in the informal dress worn at a hightech firm. Conversely, mandated uniforms at a 
department store reinforce respect for the hierarchy. 

Culture reflects the personality of the organisation and, similar to an individual’s personality, can 
enable us to predict attitudes and behaviours of employees. Culture is also one of the defining aspects 
of an organisation that sets it apart from other organisations, even in the same industry. 

Research suggests that there are 10 primary characteristics that, in aggregate, capture the essence 
of an organisation's culture: 


1. Member identity: The degree to which employees identify with the organisation as a whole, 
rather than with their type of job or field of professional expertise. 

2. Team emphasis: The degree to which work activities are organised around groups rather than 
individuals. 

3. Management focus: The degree to which management decisions take into account the effect of 
outcomes on people within the organisation. 

4. Unit integration: The degree to which units (departments) within the organisation are 
encouraged to operate in a coordinated or interdependent manner. 
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5. Control: The degree to which rules, policies and direct supervision are used to oversee and 
control employee behaviour. 

6. Risk tolerance: The degree to which employees are encouraged to be aggressive, innovative and 
risk-seeking. 

7. Reward criteria: The degree to which rewards (such 
as promotion and salary increases) are allocated— Figure 5.6 Key dimensions defining an o 
according to employee performance rather than culture 





seniority, favouritism or other nonperformance factors. 


8. Conflict tolerance: The degree to which employees are 1 Member identity 
Job 


Organisation 





encouraged to air conflicts and criticisms openly. 
2. Team emphasis 


























9. Means versus end orientation: The degree to which Individual Group 
management focuses on outcomes rather than on 3. Management focus 
techniques and processes used to achieve those results. dest people 
4. Unit integration 
10. Open-systems focus: The degree to which the Independent Interdependent 
organisation monitors and responds to changes in the 5. Control i 
N Loose Tight 
external environment. a 
6. Risk tolerance 
MEN ğ ‘ $ Low High 
As shown in Figure 5.6, each of these dimensions exists an T 
. z . A . . Reward criteria 
on a continuum. Assessing an organisation according to Performance Other 
these 10 dimensions provides a composite picture of the 8. Conflict tolerance , 
organisation’s culture. This picture becomes the basis Low mign 
3 n è 9. Means-ends orientation 
for feelings of shared understanding that members have Means Ends 
about the organisation, how things are done and the way 10. Open-system focus 
Internal External 





members are supposed to behave. 

Culture performs several important functions in 
organisations. An organisations culture provides a 
sense of identity for its members. The more clearly an 
organisation’s shared perceptions and values are stated, the more strongly people can identify with 
their organisation and feel a vital part of it. Identity generates commitment to the organisation and 
provides reasons for members to devote energy and loyalty to the organisation. 

A second important function is that culture helps to legitimise the management system of the 
organisation. Culture helps to clarify ‘authority’ relationships. It provides reasons why people are in a 
position of authority and why their authority should be respected. 

Most importantly, organisational culture clarifies and reinforces standards of behaviour. Culture 
helps to define what is permissible/appropriate and, conversely, what is impermissible/ inappropriate 
behaviour. These standards span a wide range of behaviours: from specifying dress codes and 
working hours, to how to/when to (and perhaps when not to) challenge the judgement of superiors 
and how to collaborate with other departments. Ultimately, culture helps create social order within 
an organisation. Imagine what it would be like if members didn’t share similar beliefs and values 
(but not personal beliefs or values, which may differ), and assumptions—chaos! Equitable ‘customs’, 
‘norms’ and ‘ideals’ that are conveyed by the culture of an organisation can provide stability and 
predictability of behaviour that is essential for an effective organisation. See Snapshot from Practice: 
Real-life project teams! for an example of this. 

Although this discussion of organisational culture might appear to suggest one culture dominates the 
entire organisation, in reality this israrely the case. ‘Strong’ or ‘thick’ are adjectives used to denote a culture 
in which an organisation's core values and customs are widely shared within the entire organisation. 
Conversely, a ‘thin’ or ‘weak’ culture is one that is not widely shared or practised within a firm. 

Even within a strong organisational culture, there are likely to be subcultures that are often 
aligned within specific departments or specialty areas. As noted earlier in our discussion on project 
management structures, it is not uncommon for organisational ‘norms’, ‘values’ and ‘customs’ to 
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SNAPSHOT FROM PRACTICE Real-life project teams! 





Among his many professional experiences of working in 
project management, one of the authors was involved in 
various areas of the Business for Oracle Corporation® (both 
in the United Kingdom and the United States). This enabled 
him to experience both /eadership and membership of 
a number of different project teams. Some of the larger 
projects, for example backoffice system consolidations, 
were run by a small ‘core’ team of full-time project staff, 
comprising the project manager, communications, achange 
manager and business analysts. However, the majority 
of other employees utilised by the project were seen as 
transient and, typically, subject matter experts (SMEs) were 
drawn in from across the business ‘as and when’ needed. 
SMEs ranged from a variety of technical experts to local (in- 
country) business representatives. The SMEs retained their 
functional position in the organisation, but also reported to 
the project manager regarding assigned project activities 
and tasks. This hybrid structure worked well for the 
organisation and for the delivery of projects. The culture of 
the organisation was ‘empowerment’. Everyone knew what 
their role was, and they were suitably empowered to carry 
out their role. The environment was very positive and the 
SMEs, project managers and others supported each other 
in a collective, collaborative manner. 

The author experienced a different situation at an energy 
utility company in Australia. There was a complex political 
culture with a predominantly ‘command and control’ ethos. 
The organisation was (outside of operations) a projectised 
organisation, with many large and small projects being 
attended to in a true projectised nature. As an example 
of a project structure in practice, imagine a project that 
is designed to deliver changes to core aspects of the 
business model. Included in the scope of this project was 
the redesign of the following business processes: strategic 
planning, business planning, performance management, 
benefits management and _ portfolio/program/project 








stockbroker/123RF 


management. This, as can be imagined, ‘touched’ on 
all senior positions and ‘players’ in the organisation and 
was run as a full-time project with a project manager, 
SMEs, business analysts, a parttime organisational 
change manager and a fulltime project administrator. 
The focus of the project was stakeholder management 
and communications. The project was well-supported by 
other functional departments in terms of human resources, 
procurement and corporate communications (with these 
functional departments supporting the day-to-day activities 
of the business, as well as most large or small projects). 
These two examples show the range of differing 
cultures and project structures that can typically be found 
across organisations. As a project manager (whether 
contracted or permanent), you have to quickly be able to 
adapt to the organisation's culture and to the preferred 
style of project structure: functional, matrix or projectised. 


develop within a specific field or profession. People working in a marketing department, for example, 
may have a different set of ‘norms and values’ than those working, say, in finance. 

Countercultures that. embody a different set of values, beliefs and customs sometimes emerge within 
organisations, often in direct contradiction with the culture espoused by top management. Bepending 
on how pervasive these subcultures and countercultures are, they can affect the strength of the culture 
of the organisation and the extent to which ‘culture’ influences members’ actions and responses. 


5.5.2 Identifying organisational cultural characteristics 

Deciphering an organisation’s culture can be a highly interpretative, subjective process, which often 
requires an assessment of both its current and past history. Someone seeking to learn about organisational 
culture should not just rely on what people tell them: it’s also important to consider the physical 
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Figure 5.8 Organisational culture analysis 





National Australia Bank (NAB) 


1. Physical characteristics 
Head Office: an eight-storey modern building, located at the Docklands in Melbourne, Australia. 
Smart business attire, banking formalities. 


2. Public documents 

Annual reports (financial statement), sustainability reports, investor reports, risk and capital reports. 
Strategy: Focus on the strong Australian franchise and manage international positions for value, maintain 
balance-sheet strength, reduce complexity and cost, enhance our reputation. 


3. Behaviour 

Investing in the skills and capabilities of employees, organisational culture, diversity and inclusion, talent 
management, health and wellbeing, learning and development, performance and reward, industrial relations, 
flexible working. 


4. Folklore 
Stories, anecdotes and history evidenced. 
Source: Adapted from NAB 2011, Annual Review 2011, National Australia Bank 


environment in which people work, and how people act and respond to different events that. occur. 

Figure 5.8 contains a basic analysis of the culture of an organisation. Although by no means exhaustive, 

this approach can help to yield ‘clues’ about some of the norms, customs and values of an organisation. 
Further to Figure 5.8, it is helpful to conduct the fellowing culture analysis. 


1. Study the physical characteristics ef an erganisatien: What does the external architecture look 
like? What image does it convey? Is it unique? Are the buildings and offices the same quality for 
all employees? Or are modern buildings and fancier offices reserved for senior executives or 
managers from a specific department? What are the customs concerning dress? What symbols 
does the organisation use to signal authority and status within the organisation? These physical 
characteristics can shed light on who has real power within the organisation, the extent to which the 
organisation is internally differentiated and how formal the organisation is in its business dealings. 


2. Read abeut the erganisatien: Examine annual reports, mission statements, press releases 
and internal newsletters. What do they describe? What principles are championed in these 
documents? Do the reports emphasise the people who work for the organisation and what they 
do, or the financial performance of the firm? Each emphasis reflects a different culture. The 
first demonstrates concern for the people who make up the company. The second may suggest a 
predominant concem for results and the bottom line. 


3. Observe kew peeple interact within the erganisatien: What is their pace—is it slow and 
methodical, or urgent and spontaneous? What rituals exist within the organisation? What values 
do they express? Meetings can often yield insightful information. Who are the people at the 
meetings? Who does the talking? To whom do they talk? How candid is the conversation? Do 
people speak for the organisation or for the individual department? What is the focus of the 
meetings? How much time is spent. on various issues? Issues that are discussed repeatedly and at. 
length are clues about the values of the organisation's culture. 


4. Interpret steries and felklere surreunding the erganisatien: Look for similarities among stories 
told by different people. The subjects highlighted in recurring stories often reflect what is important 
to an organisation's culture. For example, many of the stories that are repeated at Versatec, a 
Xerox subsidiary that makes graphic plotters for computers, involve their vibrant cofounder, Renn 
Zaphiropoulos. According to company folklore, one of the very first things Renn did when the 
company was formed was to assemble the top management team at his home. They then devoted the 
weekend to handmaking a beautiful teak conference table around which all future decisions would 
be made. This table came to symbolise the importance of teamwork and maintaining high standards 
of performance: two essential qualities of the culture at Versatec. Try to identify who the ‘heroes’ 
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and ‘villains’ are in the folklore of a company. What do these characters suggest about the culture’s 
ideals? Returning to the ‘story’ of Versatec: when the company was eventually purchased by Xerox, 
many employees expressed concern that Versatec’s informal play hard/work hard culture would be 
overwhelmed by perceived ‘bureaucracy’ at Xerox. Renn rallied the employees towards superior 
levels of performance by arguing that if they exceeded Xerox's expectations, they would potentially 
be left alone. Autonomy remained a fixture of Versatec’s culture, even long after Renr’s retirement. 


It is also important to pay close attention to the basis of promotions and rewards. What do people 
see as key to getting ahead within the organisation? What contributes to downfalls? These last two 
questions can yield important insights into some of the qualities and behaviours the organisation 
honours, as well as insights into some of the ‘cultural taboos’ and ‘behavioural land mines’ that can 
derail a career. For example, one project manager confided that a former colleague was sent to ‘project 
management purgatory’ soon after publicly questioning the validity of a marketing report. From 
that point on, the project manager was extra careful to privately consult. the marketing department 
whenever they had questions about their data. 

With practice, an observer can usually assess how strong the dominant culture of an organisation 
is and the significance of any subcultures and countercultures. Those who are new to project 
management can use the 10 cultural dimensions presented in this chapter as a springboard for 
beginning to discern and identify where the culture of an organisation stands, and, in essence, begin 
to build a cultural profile for a firm. 


5.6 IMPLICATIONS OF ORGANISATIONAL CULTURE 
WHEN ORGANISING PROJECTS 


Project managers have to be able to operate in several potentially diverse organisational cultures. 
First, they have to interact with the culture of their parent organisation, as well as the subcultures 
of various departments (e.g. marketing, accounting). Second, they have to interact with the project’s 
client or customer organisations. Third, they have to interact in varying degrees with a host of other 
organisations that are connected to the project. These 
organisationsinclude suppliers and vendors, subcontractors, 
consulting firms, government and regulatory agencies 
and, in many cases, community groups. Many of these 
organisations are likely to have very different cultures. 


Figure 5.9 Cultural dimensions of an organisation 


supportive of project management 
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Project managers have to be able to ‘read and speak’ the 
culture they are working in to develop strategies, plans and 
responses that are likely to be understood and accepted. 
Although the focus of this chapter is on the relationship 
between organisational culture and project management 
structure, a detailed discussion of leadership, team building 
and the human dimensions of project management can be 
found in Chapter 14. 

The linkage between strong relationships, project 
managementstructures, organisational culture and successful 
project management was referred to earlier. To explore this 
further, let’s return to the ‘dimensions’ that. can be used to 
characterise the culture of an organisation. By using these 
dimensions we could, for example, hypothesise that certain 
aspects of the culture of an organisation would support 
successful project management, while other aspects would 
deter or interfere with effective management. Figure 5.9 


CHAPTER 5 PROJECT ORGANISATIONAL STRUCTURES AND CULTURES 


attempts to identify which cultural characteristics create an environment that is potentially conducive to 
completing complex projects, involving people from different disciplines. 

Note that, in many cases, the ideal culture is not at either extreme. For example, a fertile project 
culture would likely be one in which management balances its focus on the needs of both the task and 
the people. An optimal culture would balance concern with output (ends) and processes to achieve 
those outcomes (means). In other cases, the ideal culture would be on one end of a dimension or 
the other. For example, because most projects require collaboration across disciplines, it would be 
desirable that the culture of the organisation emphasises working in teams and identifying with the 
organisation, not just with the professional domain. Likewise it is important that the culture supports 
a certain degree of risk-taking and a tolerance for constructive conflict. 

One organisation that appears to fit this ‘ideal’ profile is 3M, which has received acclaim for 
creating an entrepreneurial culture within a large corporate framework. The essence of its culture is 
captured in phrases that have been ‘thrown around’ throughout its history: ‘Encourage experimental 
doodling’, ‘Hire good people and leave them alone’, ‘If you put fences around people, you get sheep’, 
‘Give people the room they need’, ‘Freedom and autonomy to experiment are reflected in the 15 per 
cent rule which encourages technical people to spend up to 15 per cent of their time on projects of their 
own choosing and initiative’. This fertile culture has contributed to 3M branching out into more than 
60 000 products and 35 separate business units. Google applies a similar scenario with the ‘Google 20’, 
where employees are encouraged to spend 20 per cent of paid time working on ideas that may (or may 
not) materialise into a ground-breaking product for the organisation. This is purportedly how ideas 
for Google News, Gmail and Adsense were ‘born’. It has been reported that only about 10 per cent of 
Googlers are using the 20 per cent time—does this matter? They report that it’s the idea that counts: 
‘Typically, employees who have an idea separate from their regular jobs will focus 5 or 10% of their 
time on it, until it starts to “demonstrate impact.” At that point, it will take up more of their time and 
more volunteers will join, until it becomes a real project’ (D’Onfro 2015). 

A metaphor that aptly describes the relationship between organisational culture and project 
management is that of a riverboat trip: where ‘culture’ is the river and the project is the ‘boat’. 
Organising and completing projects within an organisation in which the culture is cenducive to 
project management is akin to paddling downstream (i.e. very little effort is required; balance and 
steering in the current is all that is required). This is the case for projects that. operate in a project 
friendly environment, where teamwork and cross functional cooperation are the norms and there is a 
deep commitment to excellence. Any healthy conflict is voiced and dealt with quickly and effectively. 

Conversely, trying to complete a project in a ‘toxic’ culture is like paddling upstream: much more 
time, effort and attention is needed to reach the destination. Such would be the situation in cultures 
that discourage teamwork and cooperation, that have a low tolerance for conflict, and where getting 
ahead is based less on performance and more on cultivating favourable relationships with superiors. 
In such cases, the project manager and ‘their people’ not only have to overcome the natural obstacles 
of the project, but also the prevailing negative forces inherent in the culture of the organisation. 
The implications of this metaphor are therefore important. Greater project authority and time are 
necessary to complete projects that encounter a strong, negative, cultural current. Conversely, less 
formal authority and fewer dedicated resources are needed to complete projects in which the cultural 
currents generate behaviours and cooperation that foster project success. 

The key issue is the @degree of interdependency between the parent organisation and the project 
team. In cases where the prevalent organisational culture supports the behaviours essential to project 
completion, a weaker, more flexible project management structure can be effective. 

When the dominant organisational culture inhibits collaboration and innovation, it is advisable 
to insulate the project team from the dominant culture. Here, it becomes necessary to create a self- 
sufficient project team. If a dedicated project team is impossible because of resource constraints, then 
at least a Project Matrix should be used where the project manager has dominant control over the 
project. In both cases, the managerial strategy is to create a distinct team subculture in which a new 
set of norms, customs and values evolve that will be conducive to project completion. 
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SNAPSHOT FROM PRACTICE Articulating an organisation's culture 





The Organizational Culture Inventory® (OCI®) is a frequently 
used organisational assessment too! that can be utilised to 
explore corporate culture, company culture and workplace 
culture. It is applicable to all types of organisations. 

A large service-based company in Australia was about 
to take an organisational restructuring project forward to 
‘adjust’ its internal management structure, leadership style 
and culture, to better match the needs of: 


m requirements from government 

m changing strategy (after all, structure follows strategy— 
refer ‘How Strategy Shapes Structure’ by W Chan Kim 
and Renee Mauborgne) 

m replacement of the company’s Enterprise Resource 
Planning (ERP) system. 


In order to ascertain how the corporate, company and 
workplace culture was operating, the company undertook 
an OCI survey. Based on sample data, sourced from the 
OCI website, the ‘before’ state (as developed by Drs. Robert 
A. Cooke and J. Clayton Lafferty of Human Synergistics 
International) could have looked similar to Figure 5. 10. 

By analysing data produced by the survey (as 
developed by Drs. Robert A. Cooke and J. Clayton 


Figure 510 The ‘before’ or ‘as-is’ state of the company 
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Source: Organizational Culture Inventory® (OCI): Research & 
Development by Robert A. Cooke, Ph.D. and J. Clayton Lafferty. Ph.D. 
Copyright @ 1987-2018 by Human Synergistics International. All Rights 
Reserveel. Used by permission. 


Lafferty of Human Synergistics International), the project 
was able to determine where adjustments would have 
to be carried out. These adjustments represented gaps 
between what was currently occurring (the ‘as-is’ state) in 
the organisation, compared to what was required to occur 
(the ‘to-be’ state). 

Figure 5.11 is an example of what a ‘to-be’ 
state might look like (as developed by Drs. Robert 
A. Cooke and J. Clayton Lafferty of Human Synergistics 
International). The identified gaps represented packages 
of work that had to be attended to in the project. These 
were appropriately identified and included in the 
project schedule and were resourced (by employing 
organisational change consultants) and costed into the 
project's budget. 

By taking the guesswork out of complex issues and 
effectively capturing the feelings of employees, this 
fact-based approach can be useful for establishing new 
routines, leadership styles, values and rituals in the 
reorganised organisation. 

The authors acknowledge the existence of many other 
tools that can assist an assessment of organisational 
cultural dimensions. 





Figure 5.11 The ‘required’ or ‘to-be’ state of the company 
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5.7 WORKING ACROSS INTERNATIONAL CULTURES 


In today’s globalised marketplace, projects often traverse international boundaries. This means that a 
project manager not only has to establish positive professional working relationships with stakeholders 
who may not be in the same continent or country, but who may come froma very different culture to 
the one the project manager is accustomed to working in. If this is the case, the project manager could: 


E Learn from a trusted in-country stakeholder (if one is available), for example, by sharing 
experiences about the project and describing how each would typically approach differing 
situations in their home-country. This would assist in establishing a positive rapport. 


Identify and learn about cultural differences and cultural norms ahead of time, so relationships 
begin on the best possible grounds. A tool that is gaining commercial popularity (based on research) 
to help facilitate this process is Hofstede’s Six Dimensions of International Culture (Hofstede 
Insights 2018). Readers are encouraged to review Hofstede’s model and country comparison tool. 


— https://www.hofstede-insights.com/models/national-culture/ 


— https://www.hofstede-insights.com/country-comparisorvVaustralia,china/ 


5.8 SCRUM/AGILE CONSIDERATIONS 


Scrum development teams are dedicated and empowered and are accountable for delivering the sprint 
goal. Their dedication to the sprint and the Scrum approach implies a more projectised (or at least 
strong matrix) structure. The development. team is flexible in terms of its resource mix; therefore, if 
members of the development team are not being utilised in one particular sprint, they may instead be 
deployed to other sprints. 

The Scrum master’s role is unique in terms of the ‘servantleadership’ approach towards promoting 
good Scrum practices. In a typical scenario, a Scrum master will be supporting multiple sprints across 
either the same project, or multiple projects. They will not have a substantive role to return to during 
quiet periods of work as their Scrum master role is their only role (albeit, they would of course make 
an excellent team lead for a traditional development team!) 


This chapter has examined two major organisation characteristics that can affect the implementation and successful 
completion of projects: 


4. The formal structure of the organisation and how it chooses to organise and manage resources and projects. Although 
the individual project manager may have very little say in how the firm chooses to manage projects, they must be able to 
recognise the options that are (potentially) available and be able to recognise the inherent strengths and weaknesses of 
different approaches. The options discussed in this chapter included: projectised, functional and matrix structures. 


2. The effect of ‘culture’ on the project: Organisational culture, in terms of how this affects not only the management of 
the project, but also how the project considers culture in the delivery of the project to the functions and employees 
affected by implementing the project. When working across continents and countries, the project manager will need 
to consider how different culture(s) operate, so that stakeholders can be managed more effectively and so that 
communications can be tailored to local cultural norms (among other factors). 


https://www.hofstede-insights.com/models/national-culture/ 





https://www.hofstede-insights.com/product/compare-countries/ 
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https://www.humansynergistics.com/change-solutions/change-solutions-for-organizations/ 


assessments-for-organizations/organization-culture-inventory 


https://www.hofstede-insights.com/wp-content/uploads/2018/01/Multi-focus-brochure-2018.pdf 


balanced matrix matrix structure projectised organisation 
controlling organisational culture portfolio management office 
dedicated (projectised) structures PM3/P3M (portfolio-MO) 
directive program management office supporting 
functional structure (Program-MO) strong matrix 
Hofstede’s Six Dimensions of project management office (PMO) weak matrix 

International Culture projectitis 


Review questions 


1. 


a 


N 


w 


a 


a 


Di pets) 


What are the relative advantages and disadvantages of the functional, matrix and dedicated (projectised) team 
approaches to managing projects? 


What distinguishes a ‘weak’ matrix from a ‘strong’ matrix? 

Under what conditions would it be advisable to use a ‘strong’ matrix instead of a ‘dedicated’ project team? 

How can different types of project management offices support effective project management? 

Why is it important to assess the culture of an organisation before deciding what project management structure should 
be used to complete a project? 


Other than culture, what other organisational factors should be used to determine which project management 
structure should be used? 





What do you believe is more important for successfully completing a project—the formal project management 
structure, or the culture of the parent organisation? 


Using the Hofstede tool located at: https://www.hofstede-insights.com/product/compare-countries/, review two 
differing countries for a project you have managed that has crossed international boundaries. Discuss your findings 
with a group member. 

Going to university is comparable to working in a matrix environment, in that most students take more than one class 
and must distribute their time across multiple classes. What problems does this situation create for you? How does it 
affect your performance? How could the system be better managed to make your life less difficult and more productive? 
You work for Aus Metals, which manufactures high-precision parts for the mining industry. Aus Metals has been the 
market leader for the past 20 years. It has decided to diversify by applying its technology to develop a production line 
to produce a variety of widgets for a variety of components for other industries. What kind of project management 
structure would you recommend for this project? What information would you like to have to be able to make this 
recommendation confidently, and why? 

You work for Portable Pathology. Your research and development people believe they have come up with an affordable 
technology that will revolutionise portable pathology so the service can be taken to patients, rather than patients having to 
attend pathology laboratories. The project has been named Revolve. What kind of project management structure would you 
recommend for the Revolve project? What information would you like to have to make this recommendation, and why? 

This chapter discussed the role of values and beliefs in forming an organisation’s culture. The topic of organisational 
culture is big business on the internet. Many companies use their web pages to describe their mission, vision, and 
corporate values and beliefs. There also are many consulting firms that advertise how they help organisations to 
change their culture. The purpose of this exercise is for you to obtain information about the organisational culture for 
two different companies (of your choice). If you wish, you can go about this task by simply searching on the key words 
‘organisational culture’ or ‘corporate vision and values’. The search should identify numerous companies for you to 
potentially use to answer the following questions. (Note: You may want to select companies that you would like to work 
for in the future so you can extend your knowledge of their working culture.) 
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(a) What values and beliefs are championed by each of these companies? 
{b) How do you think the organisations would each deliver projects within their culture? 
6. Use the cultural dimensions listed in Figure 5.9 to assess the culture of your current (or previous) organisation. 
{a) Which dimensions were easy to evaluate and which ones were not? 
(b) How strong is/was the culture of your organisation? 
(c) What functions does/did the culture serve for your organisation? 
{d) What kind of projects are/were easy to implement in your organisation and why do you think this is/was so? 


{e) From your experience, what kind of projects would be difficult to implement, given the structure and culture of your 
organisation? 





ORION systems (A) 


The office erupts into cheers when it is announced over the PA system that ORION has just been awarded the government 
contract to build the next generation of high-speed, lightrail trains. Everyone comes over to shake Mike Rosas's hand and 
congratulate him. It is well known that Rosas will be the project manager for this important project, which will be code-named 
‘Jaguar’. Once the celebration subsides, Rosas gazes out of the window and thinks about what he has just taken on. 


The Jaguar project will be a high-profile project that will affect procurement of future contracts with the government. 
Increased competition has raised performance expectations regarding completion time, quality, reliability and 

cost. He knows that major changes in how ORION organises and manages projects will be necessary to meet the 
expectations of the Jaguar project. 


Project management at ORION 


ORION is a division of a large aerospace company with 7000 employees. ORION evolved from a project organisation 
into a matrix structure to conserve costs and to better utilise limited resources. At any point in time, ORION could be 
working on three to five large projects, such as the Jaguar project and 30 to 50 smaller projects. Project managers 
negotiate personnel assignments with the Vice President of Operations, who ultimately decides project assignments. 
Itis not uncommon for an engineer to be working on two to three projects a week. 


Figure 5.12 portrays how new product development projects are organised at ORION. 


Figure 5.12 Organisation of product development projects at ORION 
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Project management is limited to the design and development of the new product. Once the final design and 
prototype are completed, they are turned over to manufacturing for production and delivery to the customer. A four- 
person management team oversees the completion of the project: 


m project manager—responsible for all aspects of design and development of the product 

m planning and contro/ manager—responsible for building an overall project network, scheduling, managing the 
budget, controlling and evaluating the design, program development and preparing status reports 

m electronics system engineer—responsible for providing technical expertise on electronic systems issues 

m mechanics system engineer—responsible for providing technical expertise on mechanical system issues. 


[he core work is completed by 12 to 20 design teams. Each team has a leader, who is responsible for designing, 
developing, building and testing a specific subsystem of the product. The size of individual teams varies from five to 
15 engineers, depending on the scope of their work. These engineers split their time across multiple projects. 
Design engineers run the show at ORION, and manufacturing, marketing and other groups are expected to follow 
their lead. The special status of the design engineers is reinforced by the fact that they are on higher pay scales than 
the manufacturing engineers. The overall product development and manufacturing process is captured in the master 
plan chart (Figure 5.13). 
New-product design and development evolves around five major reviews: system design review (SDR), 
preliminary design review (PDR), critical design review (CDR), test readiness review (TRR) and production readiness 
review (PRR). 
Design and development work begins within the laboratory and progresses to field tests of specific subsystems 
and ultimately final product prototypes. Once completed, the design and prototype are turned over to manufacturing, 
which begins building the production line for the new product. Manufacturing also develops the necessary test 
equipment to confirm that manufactured components perform correctly. During this time, integrated logistical support 
(ILS) teams prepare product documentation, users’ manuals, maintenance programs and training programs for the 
customers who will be using the product. 

ORION completes a major assessment of how its projects are being managed and below is a brief description of 
some of the major problems that are identified: 





m Higher than expected production costs: Once products are developed, there is a tendency for them 
to be ‘thrown over the wall’ to the manufacturing department for them to produce. Very little design for 
manufacturability is done, and the production ramp is complicated, inefficient and stressful for the people in the 
plant. 

m Quality concerns. Increased competition has raised customer expectations with regard to quality. Customers 
expect fewer defects and longer replacement schedules. ORION has a tendency to deal with quality issues 
after the fact; initiating quality inprovements after the production process is set up. Not enough attention is 
devoted to incorporating quality considerations into the original design of products. 


Figure 543 Traditional master plan at ORION 
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m Problems with customer support: User manuals and technical documentation sometimes fail to address all of 
a customer’s concerns, and customer support follow-up training is not always adequately prepared. These 
problems have contributed to increased costs in customer service and a decline in customer satisfaction. 

m ¿ack of strong project ownership: While everyone accepts that a matrix arrangement is the only way to 
accommodate all the projects at ORION, the shifting back and forth of personnel across multiple projects is 
taking its toll on the progress of individual projects. Members often fail to identify with individual projects or 
develop a ‘sense of excitement’ that could contribute to superior performance. The ‘shuffling’ of personnel 
slows progress because additional time has to be devoted to bringing returning members up to speed on 
current developments. 

m Scope creep: ORION is renowned for its engineering prowess. However, there is a tendency for design 
engineers to get so absorbed with the science of the project that they lose some focus around the practical 
considerations. This has led to costly delays and, sometimes, design modifications that are inconsistent with 
customer requirements. 


Rosas is aware of these and other concerns as he sits down with his staff to figure out the best way to organise 
the new Jaguar project. 
1. What recommendations would you make to Rosas about organising the Jaguar project, and why? 
2. How would you change the organisational Chart and Master Plan to reflect these changes? 


Seurce: Case study prepared by and used with permission of Shlomo Cohen. 


The second part of this case, ORION Systems (B): Rosas’s Plan, can be viewed online. Note that the Moss and 
McAdams Accounting Firm case, which is relevant to this chapter, is also available online. 
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PROJECT INTEGRATION 
MANAGEMENT 





Learning elements 
Understand the integrative nature of project management and the subtle 
complexities of managing projects in work environments. 


Understand the importance of project design and how this informs development of 
the project charter and project scope. 


Develop the ability to apply integrative thinking to leverage key techniques 
available to the project manager, to ensure projects are integrated and 
delivered in a controlled manner. 


Delve deeper into some of the more specific integrative activities that may be 
considered within each knowledge area. 


Be able to identify and integrate project considerations across the life cycle 
and also within each of the knowledge areas of scope, schedule, cost, quality, 
resources, risk, stakeholders, communication and information, and procurement. 


In this chapter 


6.1 Introduction 

6.2 Establishing the project 

6.3 Project planning and design 

6.4 Executing the project in the work environment 

6.5 Managing project control 

6.6 Managing change or change control across the project 
6.7 Managing project finalisation 

6.8 Managing project knowledge across the project 

6.9 Governance and the project environment 


6.10 Integrative thinking across the knowledge areas 


Summary © 
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6.1 INTRODUCTION 


Project integration management spans a number of activities to ensure the project content and 
the management of the project are successfully integrated across the life cycle of the project. It is 
important, from a practical perspective, to realise that project integration requires thinking in a 
deeper, integrative manner—across the accumulation of information gained by implementing aspects 
of each of the other knowledge areas. 

Integration may be referred to as the glue that holds together components from the knowledge 
areas (scope, cost, resources, quality, schedule, communication and information, stakeholders, risk 
and procurement). It seeks to ensure that activities are consolidated and unified; thatinterrelationships 
between the knowledge areas are coherent; and that conflicts, contradictions and discrepancies do 
not exist between knowledge areas. (PMI, 2017) 

The activities that drive integration across the life cycle approach used in this book encompass: 


1. establishing the project, including developing the project charter and assigning and determining 
the authority of the project manager 


2. project planning and design, including developing the Integrated Project Management Plan 


3. executing the project in the work environment, as defined in the Project Management Plan and 
associated documents 


4. managing project control-racking, reporting and reviewing project information 

5. managing change, or integrated change control, across the project, including implementing 
approved changes and updates to deliverables, project processes, project documents, and the 
Project Management Plan 


6. managing project finalisation, including the closure of a stage, contracts for portions of 
outsourced work or overall project closure 


7. managing project knowledge across the project, including requisite protocols and systems to 
ensure this is taking place in an effective manner. 


These activities are summarised across the life cycle in Figure 6.1. 

Particular aspects of project governance will also be discussed in this chapter, since governance 
aids in the start-up and ongoing aspects of many integrative activities, from project alignment 
through to the management of such aspects as change control, issue escalation, project reporting 
and risk. 

The final sections of this chapter review some of the more specific integrative activities that need 
to be considered across each of the other nine knowledge areas of scope, schedule, cost, quality, 
resources, stakeholders, communication, risk and procurement (management). 

Remember that ‘project integration management’ is also a knowledge area within the PMBOK 
(PMI 2017) and a unit of competency in the Australian Diploma of Project Management. 

‘Integration’ is a more holistic technique that may not be intuitive to new project managers until 
they have experienced a number of projects under differing conditions. It pertains to being able to 
think more widely and deeply across the entire project and business context; some examples of this 
integrative approach could include: 


m Whether the resulting product, service, or the results of the project, really fulfil the answer to the 
business problem and whether the problem was validated in the first place. 


@ Providing a comprehensive and Integrated Project Management Plan that ensures all activities 
are linked and validated, for example, questioning whether the Risk Management Plan (a 
subsidiary plan of the Project Management Plan) encompasses an escalation procedure that is 
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Figure 6.1 





Source: © 2018 Dr Neil Pearson 


aligned with the structure and the roles of the organisation's project management. framework, 
policy and guidelines. 


mg Whether project data is being generated accurately and on a timely basis so analysis and 
reporting of this information can inform improved decision-making in the project, and to sponsor, 
PMO and management teams. 


m When a decision is made in the project, does this take into consideration the greater whole and 
granular work activities? Has the decision been thought through in terms of what its potential 
implications may be? 


Is the project team enabled to share information across the project, and wider afield with the 
business? What about sharing information outside of the organisation, for example, with partners 
to whom work has been outsourced? 


=m Have all considerations of closure, benefits and the delivered product(s) been fully understood as 
the project transitions through the project stages towards, and including, the final hand-over? 


mg Are changes (e.g. to the triple-constraints) fully understood as part of change control? Have the 
appropriate subsidiary plans and other artefacts been updated accordingly in an integrative fashion? 


m Have aspects of the process been tailored to fit the emphasis, size and risk profile of the project? 


m Have additional plans to the Project Management Plan been developed to meet industr yspecific 
requirements (e.g. mandatory Workplace Health and Safety Plans for projects occurring in the 
construction industry)? 


m Have integrative tools been established across the project to support development activities and 
to capture and maintain all project artefacts (whether virtual or physical in nature)? 


As can be seen from this short list of examples, integration is a truly multifaceted concern. 
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6.2 ESTABLISHING THE PROJECT, INCLUDING 
DEVELOPING THE PROJECT CHARTER AND 
ASSIGNING AND DETERMINING THE AUTHORITY 
OF THE PROJECT MANAGER 


The project charter is discussed in Chapter 7. It is a summary document that provides a formal 
agreement of the project's existence, between the project’s sponsor (the business) and the project 
manager. In most organisations, the project charter provides the ‘go-ahead’ for the project to start— 
that is, to progress from the Initiating stage to the Planning stage within the PMBOK life cycle 
(PMI 2017). 

Projects should, at their outset, have a sound understanding of the problem to be tackled and 
the goal to be achieved. Before the project is scoped, the charter ensures a consistent understanding 
of the problem, the value to be derived from the project and its alignment. to strategy.(PMI, 2017) 
Subsequent scoping and planning detail kow this is to be done. 

Figure 6.2 illustrates (from a project perspective) how the charter enables the linkage of work 
between the higherlevel program, portfolio and strategy (green arrow), and how the benefits (yellow 
arrow) are progressively unpacked, understood and expressed in a measurable way. 

The charter should articulate (among other key factors for the organisation) items such as: 


E project dynamics—such as the project sponsor, project manager and reporting lines 
E project background—a s to why the project has come into existence 


E project objectives—described using the SMARTA acronym (see Table 4.1: SMARTA characteristics 
of objectives, in Chapter 4) 


Em project benefits and dis-benefits (dis-benefits are expected undesirable outcomes—the y can, for 
example, take the form of a loss of value to a department or person (termed the ‘disbeneficiary’) 
as a result of the project) 


Em strategic alignment—which elements of strategy does it assist in delivery and the expected effect 
on any key performance indicators (KPIs) 


E key stakeholders—only the ‘key’ stakeholders at this point, and their role in the project 


Em indicative budget—with tolerances clearly outlined (+/— 40% accuracy?) (see Figure 8.1: The 
Estimating Trumpet, in Chapter 8) 


Em indicative timeline—with expectations set to reflect that 
ignment and benefits this is subject to change during the further scoping and 
subsequent detailed planning stages 





Organisation's strategy ™ signatures of approval—t o proceed into full scope 





development and the Planning stage. 
Portfolio management 























Source: @ 2018 Br Neil Pearson 


a Pa The project charter effectively integrates the project into the 
Programs Operational 5 AEA = + i ifi 

work organisation’s wider reasons for the project and clearly identifies 

ae the project manager who is accountable both for delivering the 

benefits and achieving the project's objectives. 
EEE Project charter discussions (which are often held with 
Business Case 
—— senior stakeholders) can present the project manager with an 
[Scope document | opportunity to start building a positive working rapport and begin 





establishing constructive professional working relationships. It is 
important to ensure that meetings are planned and organised well 
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to support the smooth flow of discussions and to ensure the proposed content is covered and decisions 
recorded. 

The charter establishes initial expectations and paves the way for further planning to take place, 
including defining the scope of the project and the next integrative activity—-building the Project 
Management Plan. 


6.3 PROJECT PLANNING AND DESIGN, INCLUDING 
DEVELOPING THE INTEGRATED PROJECT 
MANAGEMENT PLAN 


Too often, little attention is given to a project’s approach and design. This potentially presents a 
missed opportunity as this can provide a vital structure for the project. To wrap our heads around this, 
we have only to consider the Agile (Scrum) movement that is currently sweeping across the project 
management community (emphasising the importance of ‘design’) and how this may now impact the 
design of what may have been previously a staged, incremental project design. 

A number of project management approaches (Predictive, Incremental, Iterative and Agile) were 
discussed in Chapter 2. If we combine these with the Agile approaches, as introduced in Chapter 3, the 
project manager now has many choices as to what the best design and approach would be. However, 
the project manager must define one design for the project, establish the necessary governance and 
then communicate this design and governance to the project team and wider stakeholders as required. 

In Theory: Project design shows a design that has been proposed for a two-phase project. Phase 
1 takes a Predictive approach and could, for instance, consider wider project planning for the whole 
project, fellowed by more detailed planning around Phase 1. The output of Phase 1 could be detailed 
‘ass’ process maps pertaining to the current ‘as-is’ process for hospital admissions. Phase 2 (after 
some further detailed planning) then involves moving into the ‘to-be’ design, development and delivery 
of the improved processes, job roles and IT system changes, which, due to constrained stakeholder 
access and the complexity of the integrated changes, then moves into an Agile approach. At the end of 
Phase 2, a more traditional (Predictive) whole-of-project closure takes place. 

The design in In theory: Project design would have been documented as a component of the 
Integrated Project Management Plan. It is, in fact, about. tailoring the project life cycle approach and 
building a design that will enable the most efficient use of project resources, while fitting in with the 
operational business environment to implement the changes being sought by the project. 

There are many factors to consider when designing the project approach (again, an example of 
integrative thinking!) such as: 


the physical design of the ‘blocks’ of work 
the effect of Predictive and Agile approaches on the design 


events taking place in the business and in the external environment 


other programs and projects taking place at the same time 


a 
a 
E 
™ constraints in relation to the use of resources (human and other resources) 
a 
™ the operational activities or business as usual (BaU) activities 

a 


the complexity of the requirements 
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IN THEORY Project design 





Phase 1 


Initiation 





Monitoring and controlling 
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Monitoring and Fontrolling 
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Leveraging the Predictive approach brings some ‘to-be’ processes, job designs, and IT system changes. In the 


stability to the whole project around the planning of 
resources, costs and timescales (a request from senior 
management), but later on the Agile approach provides 
flexibility in the development and implementation of the 


Agile component of the design the business receives three 
increments of product, which are shipped to the business 
and implemented at the end of each increment. The two 
phases are then closed in a traditional, predictive manner. 


Æ the risk profile of the project 


E the need for the business to see smaller increments of delivered product. 


The Integrated Project Management Plan is a concatenation of all the plans and artefacts from 
each of the knowledge areas, plus other documents (refer to Figure 6.3). 


E Fer smaller prejects: The key components of the Integrated Project Management Plan could be 
contained within a single contiguous document. 


E Fer medium- te large-sized prejects: The Integrated Project Management Plan is more likely to 
be a compendium of documents held together under document control and release control, on a 
virtual secured shared network drive. 


The purpose and details of each of the subsidiary plans and associated artefacts are discussed in 
the knowledge area chapters. 

Although it may first appear that a project manager is taking a knowledge area approach to 
planning a project, hopefully, they are actually taking a more holistic (integrative) approach to 
consider all the other knowledge areas. In Figure 6.4, for example, given the simple task of an item 
being procured, with an integrative hat on the project manager has to consider many facets beyond 
the item simply being procured. (Consider why good project managers are oftenrewarded well. They 
typically have the ability to direct, and to think, in an integrative manner for the many hundreds of 
tasks and components that can make up a typical project.) 
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Figure 6.4 i thinking 





Item to be procured 


What contract type would be 
Are there skills in the project to most appropriate? 
implement the item procured? 


ee are the risks? 
Have appropriate —/ What would be the impact to 
stakeholders been engaged? the schedule? 


Has a full costing been included Have quality considerations been 
in the budget? established? 


Source: @ 2018 Dr Neil Pearson 
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SNAPSHOT FROM PRACTICE [Integration pitfalls 





Oliver is an early career project manager. It is Oliver's first 
full life cycle project, where he is leading a small project 
team to design and deliver an information technology 
infrastructure library (ITIL) service desk process, and all 
the associated team and structural changes that must take 
place. On approval of the project’s charter, Oliver diligently 
runs through each of the other nine knowledge areas, 
crafting the individual subsidiary plans and associated 
project management artefacts. 

It takes some weeks of discussions with the key subject 
matter experts (SMEs) to workshop, design and gain 
agreement on the work to be undertaken. Before Oliver 
submits his plans to the relevant committee for approval 
(to progress into the execution stage of the project), Oliver 
asks a seasoned fellow project manager, Olivia, to review 
the key outputs in order ensure potential questions are 
discussed prior to meeting with the approval committee. 

Olivia comes back to Oliver with some interesting 
questions, including: 


m Why haven't the communication costs been 
accounted for in the project budget? 


m Why have resources been costed but are not 


m Why are work packages present in the work 
breakdown structure (WBS) but not visible in the 
project's Gantt chart? 


m There is scope for certain deliverables, but why don't 
they appear to be present in the WBS? 


m Why has only line management been involved in the 
position changes indicated in the reworked service 
desk organisational structures, and not the human 
resource manager too? 


Oliver is at first a litte annoyed that he had 
overlooked such questions. Olivia quietly reassures him 
that many early career project managers forget to truly 
integrate all aspects of project management and make 
connections across all the knowledge areas. Oliver 
thanks her for her words of wisdom and reviews all 
the plans, including subsidiary plans and other project 
management artefacts, for integrative thinking. 

What would have happened if the approval 
committee had approved the plans, trusting the Oliver 
as a professional project manager? Most likely delays, 
change requests and scope creep, and a poor track 


A ; $ record for Oliver and his maiden project. 
allocated in the resource allocation matrix (RAM)? E pse 


6.4 EXECUTING THE PROJECT IN THE WORK 
ENVIRONMENT, AS DEFINED IN THE PROJECT 
MANAGEMENT PLAN AND ASSOCIATED DOCUMENTS 


Although formally part of Chapter 6, the integrative process (like many other processes) is carried 
out throughout. the entire project life cycle. The focus is on the allocation of resources to tasks, with 
the goal of achieving the project’s deliverables. As will be discussed in later chapters, ‘deliverables’ 
should be considered in the design of a project. If a purely Predictive approach was taken towards 
the management of the project, a project manager might introduce ‘deliverables’ all the way through 
the project—t o indicate progress to stakeholders, gain continued buy-in and hand over the product to 
the business in the design of the project (deliverables assist in ‘chunking’ the work into manageable 
components). Figure 6.5 indicates a design along such lines. 

This process group is also concerned with the allocation of work, as captured in the many aspects 
of the Project Management Plan. Of particular interest are the work packages, the project schedule 
and the resource availability information, since these influence the success or failure of the execution 
of the project work. 

Behind each deliverable there could be a number of work packages, which enable the completion 
and delivery of the deliverable to the business. Figure 6.6 illustrates this relationship between the 
work packages enabling the delivery of a deliverable, and the project team member(s) being allocated 
to a work package. 
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Figure 6.5 Deliverable design 
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The continual cycle of verifying resource availability and the allocation of work is the crux of this 
process. It is the most ‘hands-on’ management part of the project work, where the project manager 
interacts closely with those responsible for the work in the work packages. 


Requests to change the project (for whatever reason) are captured as ‘change requests’. These 
change requests have the ability to affect planned work. (Chapter 5 covers the process of change 
request management in detail.) From an integrative perspective, when a change request is logged, and 
as part of the analysis of that change request, the assigned project team member must ask: Is there 
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any impact to any of the other nine knowledge areas as a result of this change request? If so, what is 
the impact? The resulting findings should be documented. 


An approved change request should have resulting ‘approved actions’ (across any of the other nine 
knowledge areas), which would been reflected back into the relevant parts of the Project Management 
Plan. The change request may have even triggered a new baseline (scope baseline, schedule baseline 
or cost baseline) from which the project is now executing. 


6.5 MANAGING PROJECT CONTROL: TRACKING, 
REPORTING AND REVIEWING PROJECT INFORMATION 


Chapter 11 discusses the techniques behind ongoing project control-the reporting, reviewing and 
decision-making based on project information. This will ensure that. the work is in accordance with the 
planned work to be carried out, as documented in the approved Project Management Plan. As we know, 
the Project Management Plan is a compendium of all the individual knowledge area ‘management plans’ 
and other associate artefacts that were developed during the Planning stage of the project life cycle. 
If performance differences are encountered, these would be highlighted through the reporting and 
reviewing of project information currently and in any forecast information for the project. (PMI, 2017) 

The project approach-hybrid, Predictive or Agile—wil] influence how project tracking will 
take place. The key ‘integrative’ concern is to ensure that tracking is integrated into the relevant 
components of the Project Management Plan and into the practices of the project team. The following 
points therefore need to be considered: 


m How project tracking information is to be tracked—w h o will update the work package status 
information and when will it be updated? Also, will the team member who is allocated to the work 
package update information at the end of every day on the value achieved, resources utilised, 
costs incurred, and time burned (among other information)? 


m How the individual work package status information will be combined to produce the daily, 
weekly and monthly reports that are required by the project manager (and other team roles) to 
track project progress. Are, for example, earned valued reports to be produced and analysed 
ona daily basis so that trends, discrepancies and respective root-cause analyses and corrective 
actions can be established? 


m What impact does the reporting and monitoring of this information potentially have on other 
aspects of the project? Does, for example, a ‘risk’ need to be raised, or an ‘issue’ escalated as a 
result of a variance from planned activity? 


@ Does the variance identified require the project manager to raise a change request that is 
submitted into the change request process for consideration? 


Em Is the work package being handled by an outsourced party? If so, how much insight into 
that outsourced package can we see? Does the resulting variance, breech any contractual 
agreements which need to be escalated as a risk or issue through the respective escalation 
processes? 


m Wider in scope, but also relevant, is the need to periodically check back with the sponsor and the 
documented business case, to ensure the project remains strategically aligned, that the business 
environment has not changed, and that the business case remains valid. 
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If the project, or part of the project, is more Agile in nature, then information on sprints, sprint 
backlog items, and the tracking of these through the development team (by updating ‘done story 
points’ against each story) would still be reported on, on a daily basis via the burndown and burnup 
charts. Refer to Chapter 3. 


6.6 MANAGING CHANGE, OR CHANGE CONTROL, 
ACROSS THE PROJECT, INCLUDING IMPLEMENTING 
APPROVED CHANGES AND UPDATES TO 
DELIVERABLES, PROJECT PROCESSES, PROJECT 
DOCUMENTS, AND THE PROJECT MANAGEMENT PLAN 


Change control is included within Project Integration Management as it is a process which spans the 
entire lifecycle of the project. It can address any of the knowledge areas individually, but more likely 
the integrative nature of a change to one knowledge area impacts many other knowledge areas. The 
Integrated Change Control process includes the raising and approval of change requests, through 
to their inclusion in relevant project management documents (including updates to the Project 
Management Plan); and the resulting changes to any of the projects baselines (Scope baseline, 
Schedule baseline and/or Cost baseline). (PMI, 2017) 

Chapter 5 covered the process of change control in detail. 

In modern project management, the project manager needs to consider the impact of changes 
beyond what is referred to as ‘the triple-constraints’ of scope, time and cost to also include quality, 
risk, resources and the organisational strategy. Refer to Figure 6.7. 

Project integration has many facets that must be reflected within a change control process. For 
example: 


m Has the project manager communicated the protocol to be followed for any change request to all 
members of the project team? 


E Isthe project team aware of any templates or ticket logging process for capturing the change request? 


Has the project team member communicated the stages and timings of the process the change 
request must go through to the requestor (stakeholder)? 


m Hasan integrative analysis of the change request taken 
place to consider, at minimum, the impact to the other nine 
knowledge areas and any areas specific to the industry they 
are working in (e.g. workplace health and safety)? 





m What is the outcome of the process? Does it require a re- 
baselining of the scope, budget (costs) or schedule? 


m How is the approved change request to be implemented? (If not 
approved, has this been communicated back to the requestor?) 


E What lessons can be learned? Have these been recorded in 
the Lessons-Learned Register and actioned so the issue is not 





ABayzeays PU Nes 1ueBIC 


encountered again? For example, if the estimating process 
and calculation for a work package were incorrect and 
components were missed in the estimation of costs, the lesson 
learned would be to update how estimating is carried out so 
future estimates are not underestimated for these types of 
work packages. 


Source: © 2018 Dr Neil Pearson 
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‘Integration’ and ensuring project integrity remains true and honest can be a complex activity for 
the project manager to oversee and ensure compliance. Hence, project integration management 
considers this to be an integrative process that continually operates across all stages of the project life 
cycle. 


6.7 MANAGING PROJECT FINALISATION, INCLUDING 
THE CLOSURE OF A PHASE, CONTRACTS FOR 
PORTIONS OF OUTSOURCED WORK OR OVERALL 
PROJECT CLOSURE 


Closing the project or a phase is a key activity of the project manager. It is where what was delivered 
is directly compared against what was planned to be delivered. This could include aspects of benefit 
(value) delivered, the performance of the project (especially cost, schedule, resources and quality 
elements) and the resourcing of the project (PMI, 2017). 

A comprehensive discussion on closure takes place in Chapter 19. Here, we will consider the 
more integrative aspects of project closure for the project phase, project contracts or the project 
itself. 

The integrative nature of activities should be considered when closing a phase, contract or project. 
A 3P approach (people, process and progress) can assist with this process. 


People 


Consider first whether the correct people are involved in the phase, contract or project closure 
activity. Representatives could be from the business, the project, or be external to the organisation. 
Integratively, the people represented at the various closure activities should cover the key aspects 
of the phase, contract or project. For example, if a phase is being closed that has implemented 
working software to the business, then representatives from the business and the project should 
be present. at the project phase closure meeting, to assess the delivered product according to the 
original scope (plus any change requests). If only the project team and the development team were 
present at such a meeting, the perspective of acceptance would potentially be skewed. Ensuring 
the correct people are present at the closure activity is vital to ensuring a holistic (integrative) 
approach is achieved. If people have left the project (and/or the organisation) and are no longer 
available, key learnings may go missed. Therefore, taking steps to capture this information before it 
is lost forms part of an integrative approach. The second ‘people’ consideration is where people will 
move to following closure of the phase, contract or project. With a contract, this may be clean-cut, 
with little project resource management required. At project closure, however, there can be many 
aspects to consider when it comes to project team members moving back into their substantive 
positions in the business (requiring human resource involvement). This encompasses being able 
to capture subject matter expertise that has been gained over time while working on the project. 
Decisions will need to be made about how the organisation can best leverage this knowledge at 
project closure. For example, perhaps it is appropriate that the project team member takes on a 
new, more senior, role in the organisation so their skills, knowledge and expertise can continue to 
be leveraged in the business—they will effectively follow the project back into the business and 
become the subject matter expert. 
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Process 


This topic is more applicable for the lessonsJearned review, which may be an agenda item on the project 
closure meeting from a business involvement, product delivered or communication perspective. Lesson s- 
learned will also form part of the post-implementation review meeting, from a project approach, processes 
and guidelines review. The project manager will, integratively, consider each of the knowledge areas at. 
the project closure meeting to ensure all activities left in progress are successfully closed out. A project 
checklist is typically used to assist the project manager to do this and an example can be seen in Chapter 
19. At the post-implementation review (i.e. after the closure of the project), the business will look to learn 
‘greater’ lessons, beyond the how the project operated across the knowledge areas. Wider organisational 
processes will be brought into question, such as processes outside of the project, the organisation’s human 
resource processes, the procurement process, the portfolio alignment process, business case gateway 
reviews, and benefit definition and tracking. Any learnings that can be passed back to the owners of 
these organisational processes will hopefully assist in the delivery of future projects. 


Progress 

The project manager will consider the fellowing issues: 

Aspects of how project tracking and reporting functioned, for example, whether the project was 
able to accurately provide status updates to inform quality decision-making. 


E The change control process, from turnaround times to the volume of requests. If there was a large 
number of change requests for a particular area of the project, does this indicate an improvement 
opportunity is available that needs to be addressed before future projects star tup? 


The deliverable acceptance process and the design of deliverables in the project: Did the project 
obtain the correct balance and granularity of deliverables? 


m How products, services and results transitioned between phases (within the project or at contract 
closure from a third party into the business, or at project closure from the project to the business/ 
customer). 


m How the business case remained current throughout the project. Were benefits validated at key 
points to ensure delivery of the project's benefits remained on track? 


A similar process is achieved in Agile, at the end of each sprint (and increment) via the sprint 
review meeting and the sprint retrospective meeting (refer to Chapter 3). 


Oy 


6.8 MANAGING PROJECT KNOWLEDGE ACROSS THE 
PROJECT, INCLUDING REQUISITE PROTOCOLS AND 
SYSTEMS 


Chapter 16 considers the wider context of project communications management by covering the topic 
of project information management. In today’s information-rich environments, the project manager 
and the project team will need to consider a number of dynamics around information. For example: 


m What information is required to be maintained by the project, as opposed to in the business? 
m Who can have access to what information and at what level (i.e. ‘create’, ‘read’, ‘update’, ‘delete’)? 


Em In what medium is the information best presented (e.g. wiki, discussion forum, intranet site)? 
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= Who within the project is responsible for maintaining the information? 
m How and when does the information get announced or communicated? 


Addressing these (and other questions) will require engaging with stakeholders so protocols 
and tools can be put in place to enable successful data, information and knowledge-sharing in the 
project environment (refer Chapter 16). Ensuring formal documents or repositories of information 
are established ensures that a single, known ‘source of truth’ exists for that subset of project 
information. 

For example, members of the project team should be able to access the ‘common’ project Lessons- 
Learned Register, so they can seek information that helps to inform work packages they may have 
been assigned. Building and maintaining a formal lessons-learned document requires a certain amount 
of work and effort, but without it a project team will have no single source of information to turn to 
regarding potentially resource-saving lessons that have been learned through prior experience. For 
example, valuable lessons may have been learned from project end stage reviews and from each 
sprint retrospective that may otherwise be lost. What this approach promotes (whether Predictive or 
Agile) is the capturing of tacit knowledge (i.e. knowledge that is ‘in people’s heads’) into a more 
explicit format—i n this case, the Lessons-Learned Register. 


In the socially aware world of modern project management, project stakeholder management skills 
and the ability to manage and (appropriately) share knowledge and information have become critical 
‘musthave’ skills for the project manager and project team members. The environment of the organisation 
may influence the style (or medium/s) used in knowledge sharing. At times, it may be appropriate for 
the project manager (with suitable backing) to politely challenge the use of traditional mediums of 
communicatiowknowledge sharing that may continue to exist in old-school organisations. Conversely, it 
may be that the project manager needs to adapt to more contemporary social media practices and must 
be prepared to change their approaches according to the organisation's and project's needs/requirements. 

Consider the following suggestions for tools for sharing knowledge (and information), adapted 
and extended from the PMI (2017, p. 103): 


m Networking events can bring together internal, external (or a combination of) stakeholders ina 
social atmosphere. 


m Comuunities of practice and special interest groups can bring together stakeholders who are 
focused around a particular area of interest. 


Æ Discussion forums and discussion groups can leverage social media technologies (e.g. Yammer, 
Confluence). 


Knowledge fairs and cafés can promote innovation and idea generation, as well as knowledge sharing. 
Coaching, mentoring and training are good ways to share knowledge and information. 


People tend to resonate well with stories. The project may have an elevator pitch or a 60-second 
story that is used to illustrate the ‘pain’ being experienced by the customer, the desired future 
state after the project, and how this will be achieved. Stories have been used for millennia to pass 
on knowledge and remain a powerful medium. 


= Workshops that are designed for a specific objective are a common format used for sharing and 
eliciting information in a project environment. 


@ Meetings can, if structured by a wellthought-out agenda, produce outcomes for more formal, in- 
depth discussions. 
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E @bservation (or shadowing) is a useful technique for probing tacit knowledge around a particular 
job function. 


In Theory: Information sharing provides an example of where the project manager has actively 
identified information and communication requirements and has put in place the technology that is 
needed for supporting the integrative nature of information and knowledge sharing across all aspects 
of the project. 


IN THEORY Information sharing 





Leading a global project across multiple geographically 
dispersed locations can present numerous challenges. 
On this occasion, the challenges were in being able to 
share and communicate (sometimes business-sensitive) 
information across a diverse set of stakeholders. The 
company had recently adopted Oracle Beehive and 
the project manager adopted the software package as 
the repository, conferencing and information-sharing hub 
for the project. 


and video and any PC screens that were shared at the 
meeting. 


m A project wiki was maintained for all project 
terminology and the documents were secured and 
shared from within the environment. 


m An intranet site, built on top of the corporate document 
management system, was constructed to present and 
share information with the rest of the business (set up 


Features of Oracle’s enterprise solution include: as part of the communication strategy for the project). 


— enterprise messaging—calendar, email, tasks and m Various discussion groups were established to cover 
contacts such topics as: data migration, technical configuration, 


x 7 A Fd, business rule changes. 
— team collaboration—discussion groups, wiki’s, 


document sharing, and search capability m Calendars were shared across the team to see into 
tasks allocated and other BaU (business as usual) 


— synchronous collaboration—conferencing, chat, 
commitments. 


presence and voicechat 

Although these facilities are available in many social 
media platforms, the benefits of using a tool such as 
Oracle Beehive was in its enterprise presence, i.e. all 
organisation employees and contractors had to use this 
single platform. 

The project manager should review and implement 
tools that will assist in the management of knowledge 
and information. The project manager in this case was 
complimented at the end of the project for having 
facilitated quality communication and information-sharing. 


m The project manager established the protocol that 
everyone in the project team had to be logged onto 
instant messaging with a status flag showing their 
availability; e.g. whether available, in a meeting, on a 
critical path activity or away. 


m All virtual meetings were recorded and made available 
to team members who could not attend the live 
meetings due to significant differences between 
respective time-zones. The recordings included voice 


6.9 GOVERNANCE AND THE PROJECT ENVIRONMENT 


Project governance includes the governance, policies and procedures that ensure: 


1. The outputs and outcomes (deliverables) of the project meet any governance requirements. 
The project manager has to consider the business environment within which the project operates 
and any overarching laws/legislation relevant to the business domain (in the countries) that. the 
final product, service or result is to operate within. Examples include: 
E overarching laws in relation to company directors, finance and tax, workplace health and 
safety and ethics 


Em morespecific laws relating to the type of organisation (e.g. aviation industry organisations, 
medical organisations). 
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2. The project complies with practices that relate to the running of the project (refer back to the 
section on the roles of supportive, controlling and directive project management offices). 


The project manager has to understand the strategic, business, portfolio and program landscapes 
so any relevant governance factors are considered in the project environment. Governance could 
affect any aspect of the project and the project manager must think in an integrative manner. 

For a project manager, this could include aspects such as: 


E program requirements in relation to project reporting, risk escalation and issue management 


Em project requirements in relation to adopting the organisation's policies, processes, templates and 
guidance on project management 


@ business policy around the definition, management and realisation of benefits (for the project), as 
defined in the business case, charter and project scope documents 


Æ industry legislation around the storage and security of information, and how freedom of 
information requests would be met within the target set by the legislation covering the 
jurisdiction in which the project takes place. 


Moving into the project environment, there could be more specific governance the project manager 
has to be aware of and include in the design and planning aspects of the project. This could include 
items such as: 


™ establishing the relevant committees to oversee the project, which could include a change control 
board for the management of change requests 


Em user groups or user committees the project must engage with 


@ project reporting arrangements—audience, style, content and source of information for the 
project’s reports 


@ financial approval and audit requirements, whether these are manually tracked or implemented 
through the organisation’s financial and procurement IT systems 


Em actively promoting the ethical standards and guidelines of project management, for example: 


— The Project Management Institute’s Code of Ethics and Professional Conduct (https://www. 
pmi.org/about/ethics/code) 


— The Australian Institute of Project Management's Code of Ethics and Professional Conduct 
(https://www.aipm.com.au/documents/aipm-key-documents/aipm_code_of_ethics_2015.aspx) 


m Ensure everyone in the project team, and other stakeholders, are aware of their role in the 
identification, escalation and management of risk according to the organisational policy on risk 
(such as interpretations of AS/NZS ISO 31000:2009 Risk Management - Principles and Guidelines 
and ISO 31000:2018 Risk Management - Guidelines) 


Em Ifthe organisation is ISO 9001 accredited (a general quality system accreditation), this will potentially 
affect the project in how it is executed and documented. ISO requires auditability, therefore the 
project could have to commit to keeping audit trails on all project information and decisions. 


Figure 6.8 summarises the different contexts of governance outlined above. Typically, it is a subset 
of all these types of governance that would be considered by the project manager. 

Table 6.1 offers a snapshot of governance and standards that may be applicable to some Australian- 
based projects. A project manager would typically construct a similar table for the country the project 
is operating within, plus information that covers other countries if the product, service or result is to 
be deployed overseas. An ideal place to capture this high-level identification of applicable governance 
and standard would be in the project scope document. Obviously, there could be implications for 
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Figure 6.8 





Intersection = governance relevant to our project 


Source: @ 2018 Dr Neil Pearson 


the remainder of the Planning stage, such as the generation of work packages and/or tasks to 
deliver a work package, among other considerations such as communication, risk and information 
considerations. 


Table 61 Examples of standards encountered in Australia 


Category Title Link 
The wider country/industry Corporate Governance Principles and WWW.asx.com.au/documents/asx-compliance/cgc- 
governance Recommendations (ASX) principles-and-recommendations-3rd-edn.pdf 
AS8015-2005: Corporate Governance of https://infostore.saiglobal.com/en-au/Search/ 
Information and Communication Technology All/?searchTerm=AS8015 
AS/NZS ISO 14001:2016 https://infostore.saiglobal.com/en-au/Standards/ 
Environmental Management Systems - AS-NZS-|ISO-14001-2016-1881872/ 
Requirements with Guidance for Use 
Freedom of information Act 1982 https://www.oaic.gov.au/freedom-of-information/foi-act 
AS/NZS 4801 Occupational Health and Safety https://www.saiglobal.com/Assurance/ohs/ASNZS_4801_ 
Management Systems OHS_Standard.htm 
AS/NZS ISO 9001:2016 https://infostore.saiglobal.com/en-au/Standards/ 
Quality Management Systems - Requirements AS-NZS-ISO-9001-2016-1845270/ 
The Company Directors Corporate Governance Wwww.companydirectors.com.au/DirectorResource-Centre/ 
Framework Corporate-Governance-Framework 
Portfolio/ program/project AS ISO 21504:2016 https://infostore.saiglobal.com/en-au/Standards/ 
governance Project, Programme and Portfolio Management - AS-ISO-21504-2016-1865515/ 


Guidance on Portfolio Management 


ANSI/PMI 99-001-2017 https://www.pmi.org/pmbokguide-standards/foundational/ 
The Standard for Project Management pmbok/sixth-edition 
AS ISO 21500:2016 https://infostore.saiglobal.com/en-au/Standards/ 
Guidance on Project Management AS-ISO-21500-2016-1865514/ 
AS/NZS ISO 31000:2009 https://infostore.saiglobal.com/en-au/Standards/ 
Risk Management - Principles and Guidelines AS-NZS-ISO-3 1000-2009-1378670/ 
Organisational governance High-level governance For example: 
https://www.qut.edu.au/about/governance-and-policy 
Policies supporting governance For example: 
www.mopp.qut.edu.au 
Procedures Details processes and work instructions that support the 


delivery of process in an organisation 
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In summary, governance and standards that need to be followed in the project could be sourced 


from the: 


organisation's internal policies, procedures and processes 
project and/or program management office 

sponsor 

industry/sector within which the organisation sits 


wider environment within which the organisation operates (country or global). 


6.10 INTEGRATIVE THINKING ACROSS 
THE KNOWLEDGE AREAS 


The final sections of this chapter review each of the nine knowledge areas (scope, schedule, cost, 
quality, resources, risk, stakeholders, communication and information, and procurement) and some of 


the specific integrative considerations relevant to each knowledge area. 


To help the project manager understand where some of the considerations have been raised, it 


often helps to think in multiple dimensions as illustrated in Figure 6.9. 


Figure 6.9 





Monitoring and controlling 























` 

Scope Stakeholder 

Schedule Communications 
Cost Risk í | 
T> > an> Quality Procurement (ra) > Bd => 
y Resource T 7 
a Sa | 
RTM en 


Source: © 2018 Dr Neil Pearson 


1. Think backwards! Are factors that have already been established and approved now being changed and 
therefore require re-confirmation of approval in order to move forward? 

2. Think forwards! What is the impact on events that have yet to occur in the project? What has already been 
confirmed? What else needs to be done? What needs to be changed? And what should now not be done? 

3. Think more deeply into, and across, the other knowledge areas. For example, if a new stakeholder is 
introduced, what communications are required? Does this change the structures for reporting? What effect 
will this have when implementation takes place? 

4. Check for integrative effects on downstream projects that precede the project (check this also if there is a 
degree of parallelism taking place). If we change a deliverable, does this have an impact on considerations 
other project managers may have to take into account? 

5. Apply integrative thinking to check for any potential impacts on ‘going forward’ into any projects that are 
upstream from the project. Does a change we have made in our project influence the design of a subsequent 
Project? If so, who needs to be notified? 

6. Consider what impact project decisions may have on the current and future environment: this may be from a 
compliance perspective, or may be driven from a company ethics perspective. 

7. Finally, consider the impacts of the project on the business. For example, if a new process is introduced, 
how does this impact on operational employees? Will this raise any organisational change management 
consideration or communication requirements that now need to be planned for in the project? 
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6.10.1 Project scope integration 


Project scope integration includes aspects of project and processes, through to the validation of the 
scope document and deliverables at project closure. Typical activities carried out in relation to scope 
integration can be seen in Table 6.2. 


Table 6.2 Project scope integration 


Initiating m Develop the scope (captured in the scope document and accompanying WBS). 
m Review lessons-learned from past projects (subsequently documented in the Scope Management 
Plan) and how these apply to the current project. 

m Develop initial WBS. 

m Estimate the project's overall (projected) cost and duration—gaining agreement with executive 
management ât the Initiating stage of the project this could typically add or deduct 20-30% in costs 
and time. 

Develop and communicate the Scope Management Plan (including the change request control process). 
Gain approval of the project scope document and the Scope Management Plan. 


Further develop the Project Management Plan to support the approved project scope. 

Apply the change request process to any scope changes. 

Continue to validate the project’s objectives, typically at steering committee meetings or gateway 

review points. 

m Continue to improve the project scope control processes as documented in the Scope 
Management Plan. 

m Review how the objectives identified in the scope document extend into the other knowledge areas, and 

what does not need to be planned in the other knowledge areas as a result of this review. 


Planning 


Executing m Continue to validate the project objectives. 
m Apply the change request control process for any change to the project and reviewing the impact 
of the change request across the other knowledge areas. 
Ensure the scope document is aligned to approved scope changes. 
Continue to improve the project scope control processes. 
Deliver the deliverables, as defined in the project scope document and project schedule. 


Validate ‘results produced by the project’ against ‘what was defined within the scope document’ 

(including the project’s objectives, outcomes, outputs and benefits)—did the project deliver what it 

promised to deliver? 

m Review all change requests to ensure the delivery of ‘changed requirements’ took place and that 
there are no outstanding changes requests. 

m Capture ‘scope lessons-learned’. 

m Hand over final project deliverables to the relevant business owners 


Closing 


6.10.2 Project schedule integration 


Table 6.3 outlines some of the integrative activities a project manager would consider from a project 
schedule integration aspect. 


Table 6.3 Project schedule integration 


Initiating m Leverage the initial outline WBS to determine high-level estimates for the duration of activities. This 
would also include an estimation of resource requirements to determine how long each resource is 
required for. The costs identified would, for example, be passed into the project cost management 
processes and recorded in the project’s budget. 

m Develop the Schedule Management Plan. 
m Develop the high-level timeline or high-level project schedule to include in such documents as the 
project charter. 


Planning m Continue to develop the WBS and work packages. 

m Continue to develop the Schedule Management Plan. 

m Develop the detailed project schedule, involving obtaining more detailed/ accurate estimates than 
were sought at the Initiating stage. 

m Allocate resources and costs to the project schedule (using a software package to ease the 
maintenance of schedule data). 

m Review the project schedule to look for efficienc y-maximising opportunities (including opportunities 
to fast-track and crash the project schedule). 

m Update the scope document with the list of scheduled milestones and deliverables. 

m Obtain baseline and approval of the project schedule prior to project execution (the schedule baseline). 

m Communicate the Schedule Management Plan and the project schedule to the project team and 
other stakeholders as required. 


Continued 
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Continued 


Executing 


Closing 


Maintain the WBS and project schedule. 

Monitor the baseline project schedule for discrepancies between, for example, planned and actual 
activity durations. Invoke the change request process for any changes to the project schedule, to 
ensure the change request has been appropriately analysed and the full impact of a request on the 
schedule is captured for later approval / no approval. On approval, the project schedule could be 
potentially re-baselined. 

Report on project progress in a defined and agreed format. Project status reporting may include the 
preparation of earned value management (EVM) information (refer to Chapter 1 1). 

Allocate activities and work packages to internal and external personnel (e.g. contractors). 

Monitor the performance of work packages and update the project schedule with tracking 
information. 

Ensure milestones and deliverables are achieved, and report on milestone and deliverable 
progress. 

Closely monitor activities on the project schedule’s critical path. 

Obtain approvals when deliverables are delivered to the customer. 

Update the project team (and others) on the project’s schedule, typically at project team meetings 
(where ‘last week’, ‘this week’ and ‘next week’ allocations and statuses are discussed). 


Final project reporting; baseline versus actual schedule. 

Checking to ensure that all tasks/work packages have been completed according to the project 
schedule. 

Capture scheduling lessons-learned. 


Key outputs of scheduling can potentially include a number of documents. 


E The project schedule: This is usually captured and maintained within a software package, such as 


Microsoft® Project (or the business may have a preferred tool). 


E The Schedule Management Plan: This document typically includes: 


— governance and approvals—for example, under what circumstance(s) is the change/ 
variation control process invoked? What are the approval levels of the project manager and 
steering committee? 


— details of estimates—captured in the Initiating stage and further developed in the Planning 
stage. This could be a simple table of tasks/work packages by reference, the type of 


estimating used, and the value (resources, durations, costs) of the estimate, captured 
by stage. This provides a valuable audit trail of ‘how’ and ‘what’ was estimated (and by 


whom), and the resulting value of the estimate. Not only can lessons be learned from such 
information, but transparency is provided about the process of estimating. 


— allocations of tasks/work packages to an accountable person who is responsible for delivery 
(a simple table may suffice )—this can also be captured within the software package as the 
project schedule is developed. 


Integration of the schedule aspects of the project forms one of the most critical activities for a 
project manager. Communication is key to ensuring that all involved in the project know what work 
packages (and associated tasks) they are accountable for delivering; monitoring progress to ensure 
the project remains on-track; and identifying any problems early on in the non-completion or delays 


in work packages. 


6.10.3 Project cost integration 


Project cost management is often a complex activity. It involves bringing together many sources of 
information—the WBS, estimating information, information systems, and accounting policies and 
procedures—to arrive at a project budget. Some of these activities, captured against each stage of the 
project lifecycle, are shown in Table 6.4. 
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Table 6.4 Project cost integration 


Initiating m 


Planning L 


Executing L 


Closing L 


Estimate costs across the WBS. This will also include the estimation of resources required and 
how long each resource will be required for, in addition to materials, plant and equipment, 
leading to an estimate of the total cost of the work package. 

Review the WBS from a ‘make or buy’ analysis perspective. 

Develop the Cost Management Plan including any finance-related governance. 

Identify and possibly approve any identified large capital items and long leadtime items. 
Identify funding sources and signatories to obtain release of funds into the project. 

Ascertain project funding sources and develop the high-level project budget. 

Request access to corporate systems, such as financial and Enterprise Resource Planning (ERP) 
systems. 


Continue to develop the WBS and work packages. 

Use estimating techniques to ensure improved accuracy, to bring the project budget within the 
industry-accepted 5-10% margin (or the accuracy level as defined by the organisation). 
Continue to develop the Cost Management Plan. 

Baseline setting of the project budget and approval of the project budget, prior to the 
Executing stage. 

Communicate both the Cost Management Plan and the project budget to the project team and 
others, as required. 

Arrange for the setting-up of project financial structures in financial and ERP systems according 
to company standards. 


Continue to maintain the WBS, project schedule (network) and the project budget. 

Monitor the baseline project budget for the impact of change requests. Invoking the 
change request process for any changes to the budget, to ensure the change(s) have been 
appropriately analysed and their full impact is approved/not approved prior to any documents 
being updated and the project budget being re-baselined and reissued. 

Report on the projects progress as part of project status reporting. Note that project status 
reporting may include the preparation of earned value management (EVM) information. This 
would include cost figures such as planned value (PV) and actual costs. 

Monitor the cost performance of work packages, to ensure completion within agreed cost 
parameters (to time and quality specifications). 

Update corporate systems with financial information and approvals (ranging from contractor 
and project staff timesheets, to invoices and purchase orders). 

Final project reporting (baseline versus actual budget). 

Update the organisation’s corporate systems with final project costs. 

Close access to systems, to prevent any future projects from booking costs to the account 
codes setup for this project. 

Capture cost-related lessons-learned. 


6.10.4 Project quality integration 


The integration of quality across the project life cycle requires a complex interaction of project 
management activities spanning scope, time, cost, human resources, risk, procurement and 
communications. Table 6.5 provides an overview of the functions of quality across the life cycle of a 
project in the context of project quality integration management. 


Table 6.5 Project quality integration 


Initiating L 
C] 


Establish the quality assurance and quality control process requirements of the product/ 
service. 

Establish quality assurance and quality control processes from a project management 
perspective. 

Brainstorm the quality criteria grid. 

Establish the cost of quality (CoQ) to the project. 

Establish the cost of poor quality (CoPQ) to the project (i.e. costs associated with the current 
processes being addressed by the project that create poor quality products, services, or 
results that have to be rectified later). 

Document quality in the scope document and gain agreement on the broad specifications for 
quality with sponsor(s) and client(s). 

Review ‘lessons-learned’ regarding quality from previous projects. 


Continued 
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Continued 
Planning m Build the Quality Management Plan: detail all aspects of quality assurance and quality control 
(from both project management and product/service perspectives). 
m Gain approval for the Quality Management Plan. 
m Review any risks associated with decisions made around quality assurance 
and quality control. 
m Establish any additional work packages, tasks or deliverables arising as a result of quality 
assurance and quality control planning. 
m Ensure the planned durations of existing work packages and tasks allow for quality activities 
(that are a direct result of building quality into the project). 
m Ascertain the cost of building quality aspects into the project and articulate this cost, ensuring 
the project's budget includes necessary coverage of these costs. 
m Ensure work packages include all relevant quality assurance criteria and quality control 
mechanisms. 
Executing m Ensure the recipient of the work package understands the implications of the quality criteria 
they will be performance-managed against. 
m Tightly manage the control of quality; raise variations for quality variances and put in place 
action plans for rectification, postrootcause analysis. 
m Consider holderspecific quality meetings with the customer and suppliers (as required) to 
raise/ensure awareness about, and control of, quality. 
m Sign-off of deliverables, to include acceptance to the stated quality criteria. 
m Continually seek efficiencies in the project's delivery through continuous improvement 
processes. 
Closing m Ensure all project and product/service quality outputs/outcomes have been achieved. 


m Obtain final quality sign-offs, as required. 

m Interact with suppliers about final defect lists and any procurement-related activities (such as 
withholding payments). 

m Record lessons-learned about quality for future projects. 


As indicated in Table 6.5, there are many considerations and complexities involved in applying 
quality as an integrative process across the life cycle of a project. Quality aspects should not be 
under-estimated. The impact on the project’s final success or failure could range from ‘life-critical’ to 
irreversible reputational damage (both to the project and the organisation as a whole). 


6.10.5 Project resource integration 


It is important to consider activities across the entire life cycle of the project. This becomes ever 
more complex in today's business environments as resources regularly ‘come and go’ from projects. 
Table 6.6 indicates some of the main activities the project manager is likely to become involved with. 

As can be seen, the integrative elements of resource management can be extensive. Think about 
what you would potentially include as additions to this list of activities. 


Table 6.6 Project resource integration 


Initiating m Identify resource requirements in developing the WBS and in subsequent estimating. 

m Capture the human resource requirements within the Project Resource/Skills Matrix. 

m Capture other resource commitments in a Resourcing Matrix and/or the project schedule. 
These could include tools, equipment, raw materials, etc. 

m Develop the Resource Management Plan, including identifying any organisational processes 
and procedures that have to be adopted into the project (typically recruitment, performance 
management and termination) in relation to human resources. Establish project governance 
in relation to human resource aspects. Identify how the team/individuals are to be rewarded 
(consider cost implications and capture these in the project budget). 

m Define the project's organisational structure, roles and supporting role fact sheets and/or role- 
Position descriptions. 

m Establish the project’s culture. 

m Identify early on, and make arrangements for, resources (e.g. human, tools, equipment) that 
are in high demand, or for which there is a general skills shortage. 


Planning 7 


Executing 


Closing 
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Continue to develop the Resource Management Plan (ensure all types of resources are 
considered, human and other). 

Capture and analyse all resource details in the Resource/Skills Matrix, including the training 
needs analysis, details of certifications, and performance dynamics (KPIs and targets). 
Analyse the resource types and identify the most efficient method of using these resources 
across the life cycle of the project. Allocate resources to the project schedule and carry out 
resource levelling, as required. 

Start recruiting the project team. 

Establish a project team agreement (if required) and project identity. 

Develop a RASCI (who is Responsible for the task, who is Accountable for the task and what 
has been done, who will provide Support for the implementation of the activity/process/ 
service, who can be Consulted about the task and who should be Informed about task 
progress or decisions in the task). 


Ensure a project kickoff meeting is carried out. Establish project ground rules and culture. 
Build (acquire and recruit) the project team. 

Acquire other resources (tools, equipment and raw materials) required by the project. 
Engage with contract and procurement activities for the acquisition of resources as required. 
Organise and induct project team members. 

Monitor the performance ofthe project team. 

Carry out team meetings and team-building activities. 

Allocate tasks to the project team. 

Build relationships. 

Manage and resolve conflict. 

Manage resource commitments and availability. 

Update resources utilised in the project schedule, so EVM information generated is accurate. 


Have a closure party/meeting. Remember that in general, people need closure and thanks/ 
recognition of some kind, whether this is a group celebration or individual thanks. 

Release staff from the project, contract, secondment or other. 

Conduct final team and individual performance reviews. 

Pay retention and other bonuses, as agreed. 

Capture resource lessons-learned. 

Link to contracts and procurement for the closing-down of any other resource related 
contracts. 


6.10.6 Project stakeholder integration 


Stakeholder management can be complex. This is unsurprising if we consider the variety of experience 
and industries of individual or groups of stakeholders. The impact they can potentially have across the 


project management life cycle, and on the knowledge areas, can be significant. Therefore, stakeholder 
management can be an intensive activity for the project manager. Table 6.7 provides asnapshot of some 
of the activities the project manager may need to consider with regards to stakeholder management. 


Table 6.7 Project stakeholder integration 


Initiating L 


Identify stakeholders: within the project, subject matter experts, in the business and external 
to the business (including potential paying customers}. Ensure a comprehensive identification 
activity takes place. 

Engage with the sponsor to identify stakeholders they consider should be included in the 
project. 

Establish which stages and knowledge areas each stakeholder will contribute to. 

Analyse the stakeholders: work out, for instance, where power/interest sits. 

Analyse the stakeholders from an organisational change management perspective. 

Holding a stakeholder ‘meet and greet’ session to set initial project expectations (expectation 
management). 

Define role expectations of the stakeholder to the project and of the project to the stakeholder. 
Ensure key stakeholder involvement in the project design. 

Run project kick-off meeting(s). 

Build rapport and co-ownership of the project. 

Identify any organisational governance (or policy/policies) where stakeholders are to be 
considered and the mechanisms for contacting them. It is possible that contact with some 
stakeholders (most commonly external groups) may only be possible via defined internal 
stakeholders in the organisation. 


Continued 
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Continued 


Planning m Gain further stakeholder involvement and buyin into the detailed design of the project. 

m Generate interest in stakeholder co-ownership. 

m Identify new stakeholders as planning progresses, and as further subject matter experts are 
involved. 

m Review the project information and communication aspects of existing and new stakeholders. 

m Identify costs associated with stakeholder engagement activities and ensure these are 
included in the project budget. 

m Plan for the engagement of stakeholders: who in the project team is primarily responsible for 
Managing the working relationship and business activities with a stakeholder(s)? 

m Manage organisational politics and associated company dynamics as the impact of the 
project design becomes apparent. 


Executing m Ongoing stakeholder management and identify new stakeholders, for example, stakeholders 
who are to receive the finished deliverables and/or final product. 
m Manage the handover of deliverables to stakeholders. 
m Address concerns. If concerns become issues, the project manager will have to become 
involved in clarifying and resolving the issues. 
m Carry out stakeholder surveys to ascertain how engagement with stakeholders is perceived 
and follow up with appropriate actions. 


Closing m Communicate the project's success to all project stakeholders. This may require generating a 
number of different messages to the different types of stakeholders on the project. 
m Personally thank all stakeholders involved in the project (you never know when you may 
require input from a stakeholder in future projects!) 
m Capture and action stakeholder lessons-learned for future projects (and for the organisation 
as a wider entity). 


6.10.7 Project communication and information integration 


Project communication is integral to all aspects of the project life cycle. Table 6.8 illustrates some of the 
activities that a project manager will have to make arrangements for within the project environment. 


Table 6.8 Project communication and information integration 


Initiating m Develop the Communications Management Plan. 

m Initiate the Communications Matrix. 

m Develop the project’s big picture and early communication of this vision to the various 
stakeholder groups. 

m Develop the project charter (may also be considered a scoping activity). 

m Establish the project library. 

m Identify and gain access to project management information systems and/or corporate ERP/ 
financial systems. 


Planning m Continue to develop the Communications Management Plan and communicate the plan to the 
project team. 

m Develop the Communications Matrix in more detail. 

m Closely manage sending of communications identified in the Communications Matrix. 

m Monitor feedback from the communications sent, and include/consider in project reviews/ 
meetings. 
Develop, review and distribute project status reports. 
Initiate the Communications Register to record formal communications sent from the project. 
Conduct project team meetings. 
Maintain the project library and any project management information system. 
Establish (and subscribe) to any electronic communication tools required to communicate with 
‘virtual’ team members. 
Put in place systems to capture and share knowledge and information across the project team. 


Address concerns to avoid any issues. If concerns become issues, the project manager will 
have to become involved in clarifying and resolving them. 

Continue to send communications as identified in the Communications Matrix. 

Enhance monitoring of feedback from sent communications. 

Develop, review and distribute project status reports. 

Conduct project team meetings. 

Maintain the project library and any project management information system. 

Prepare final project status report(s). 

Ensure the project documentation is updated within any project management information 
systems / project library, before archiving project information. 

Capture communications lessons-learned. 

Conduct postimplementation reviews. Refer to Chapter 19. 


Executing 


Closing 
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6.10.8 Project risk integration 


A lot of benefit is achieved by applying each knowledge area across the life cycle of the project. ‘Risk’ 
is especially important when applied in an integrative manner. Some of the key elements of project 
risk integration are shown in Table 6.9. 


Table 6.9 Project risk integration 


Initiating m Establish the risk context within the external environment, the organisation and within the project. 

m Seek advice on the risk management framework and the process to be applied to the project. 

m Develop the Risk Management Plan and define how the risk management process is to be applied. 

m Identify high-level risks for inclusion in the scope document. This may also necessitate opening up 
the project Risk Register; to analyse the risk rating of any identified risks. Remember: Risks can be 
sourced from an activity that has been defined in any of the knowledge areas. 

m Plan an approach to risk management in the project (i.e. identifying specific risk roles and 
responsibilities) (typically captured in the Risk Management Plan). 

Develop the initial Risk Register. 

Planning m Undertake detailed riskidentification, analysis, evaluation, treatment and contingency planning. 
Risk identification could involve workshops and brainstorming session(s), using some of the risk 
identification techniques (such as RBS, WBS, Delphi and PERT). 

m Continue to review all other project activities taking place (including but not exclusively the other 
knowledge areas), with the aim of identifying any relevant risks and capturing the risks as described 
in the Risk Management Plan. 

m Further develop the Risk Register. 

m Continue to develop the Risk Management Plan and its approval. 

m Communicate the Risk Management Plan and its approach to the project team. 

Executing m Monitor risks (as you would for any dimension of the project). Watch for changes to individual risk 


profiles and new risks that may occur as the project progresses. 

m Invoke the change request process (refer to Chapter 7) when a risk becomes an issue. Be suitably 
prepared by having contingency plans developed for high-probability/high-impact risks. 

mw Communicate risks. This could be at regular team meetings or in project status reports. 

m Make improvements to the risk management process as opportunities arise through the lessons- 
learned process. 


Closing m Close out any risks (and make sure the business is aware of any open risks in handover 
documentation). 
m Report the final project Risk Register as part of the final project closure report. 
m Capture risk lessons-learned specific to the project content, and/or across the other knowledge areas. 


6.10.9 Project procurement integration 


Procurement is integral to all aspects of the project life cycle; from initial ‘make-buy’ decisions on 
long lead-time items, through to project closure (ensuring all suppliers have delivered to mandated 
specifications and contractual agreements). Key activities of procurement (as distributed across the 
project life cycle) are captured in Table 6.10. 


Table 610 Project procurement integration 


Initiating m Establish the procurement approach across the project. 

m Define roles and responsibilities in relation to procurement activities within the project. 

m Engage with the organisation’s procurement and contracts department to draw standard policy and 
procedure into the project and to establish the governance policy and procedures to be applied to 
the project. 

m Identify the initial requirements for items to be procured, especially in relation to long lead-time 
items and large capital purchases. 

m Gain approval (according to the governance procedure) of any long lead-time item and capital 
purchases. These typically fall outside the accountability of the project manager and may reside 
instead with governance committees (such as the project steering committee and/or sponsor). 

m Define the procurement relationships and identify any specialist skills to be employed within the project. 

m Consider ‘make or buy’ decisions to record in the Procurement Management Plan. Consider the 
impact of these on the project budget and sources of funding. 

m Document all procurement management activities within the Procurement Management Plan. 

m Review lessons-learned from previous projects (from a procurement-perspective). This may extend 
to projects outside the organisation, where information is available (e.g. in trade magazines, 
journals and press releases). 


Continued 


PART 2 POSITIONING PROJECTS 


Continued 


Planning 


Executing 


Closing 


Continue development of the Procurement Management Plan. 

Establish any tender processes, roles and responsibilities. 

Identify and plan the approach to be taken for all other (non-long-lead time and large capital) 
purchases that have been identified during the detailed planning of the project. Leverage the WBS 
and other project artefacts. 

Develop any required RFI, RFQ, RFT, RFPs. Note that the development of these various tender 
documents can consume a considerable amount of time and resources. Therefore, the project team 
and/or project manager should make sufficient allowance for this in the project schedule. 

Allow time for the procurement and contracts department to review and make adjustments to the 
contract, according to organisational policies and procedures. Often, the legal department will be 
involved in tender preparations and contract negotiations. Again, allowances must be built into the 
project schedule for potential delays. 

Review all procurement activities (and their potential impacts on the project schedule). 

Review risks from a procurement-perspective and include any risks on the project Risk Register. 
Publicise open tenders and/or invite suppliers to closed tenders. Again, ensure any leadtimes are 
incorporated into the project schedule and incorporate potential knock-on effects in the turnaround 
times of tenders. 

Notify each successful supplier. (But only notify the unsuccessful supplier when each successful 
supplier has signed a legally binding contract.) 

Once all successful suppliers have been selected from the tender process, engage each in contract 
negotiations. Establish all of the contract performance criteria and related schedule of payments as 
a part of contract negotiations. 


Monitor contract performance criteria and take corrective actions where necessary (this may be 
included as a part of the quality continuous improvement process). 

Make payments against the agreed schedule of payments (progress payments), according to the 
performance criteria that were contractually agreed. 

Monitor changes in profiles, existing risks raised during project planning, and raise any new risks, 
as and when these occur. 

Maintain records of deliverables and any outstanding defects for later reconciliation during the 
project, and at project closure. 

Apply the project change/variation process to any deviations in scope and changes to the project 
that are a result of changes to procurement activities or non-conformance (quality aspects). 
Continue to manage stakeholders and build relationships with suppliers to ensure alignment 
with project objectives. Trust in the supplier relationship is not (unfortunately) automatic and has 
to be built and maintained across all stages of the project life cycle, from initiation through to 
closure. 


Conduct final assessments of contract deliverables, based on the defined acceptance criteria. 
Agree on defect or ‘fix’ lists and the payments to be withheld until such problems have been 
resolved. On a cautionary note, be aware that although standard percentages are usually agreed 
within a contract for such situations, if the monetary value of the defect(s) exceeds the monetary 
percentage withheld, it may be possible for the supplied to walk away from the contract by 
declaring bankruptcy. 

Handover warranties and guarantees to the business owner. 

Review the performance of all suppliers and contractors and notify the procurement and contracts 
department of the outcomes of this assessment. Especially highlight where performance has 
been sub-par and where consideration should be given to potentially not using those suppliers/ 
contractors for future projects. (This information would also be captured as lessons-learned for the 
benefit of future projects.) 

Conduct final, formal, contract close-out activities (as defined in the organisation's policies and 
procedures). 


Table 6.1@ shows the complexity and variation of procurement activities to be considered in the 
Initiating, Planning, Executing and Closing stages of the project. As illustrated, many integrative 
aspects of procurement management are tied in with project quality. Procurement risks must also 
be monitored and controlled across the life cycle of the project, to avoid potential impacts on the 
schedule and costs. 
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The complex nature of integrative thinking has been explored throughout this chapter, including: 


m developing the project charter and the overall project approach and design 


m the importance of integrating artefacts generated through attention to the nine knowledge areas, as an Integrated 
Project Management Plan 


the integrative nature of managing change requests and the impact of change to all areas of the project, including 
scope, schedule, resources, costs, quality, risk, stakeholders, communication and information and procurement 
reporting of project information, and ensuring the ability to collect information in an accurate manner is built into the project 
the allocation and management of ongoing project activities 

ensuring systems exist for the collection and sharing of project information across and outside the project 

the closing of a project stage or the whole project and making sure any lessons-learned are captured and leveraged 
the importance of ensuring good governance foundations are laid and built upon for the project 

a discussion of ‘integrative thinking’ across the knowledge areas. 





This chapter has also provided linkages to material covered in future chapters in this text (where further detail and 
discussion of the various topics and techniques is found). 


Organisation 


Information and 
Technology 


Process 





Source: Adapted from Yeates D, Cadle J & Paul D 2014, Business 
Analysis, 3rd edn, BCS Learning & Development, The Chartered 
Institute for IT 


© Assist Knowledge Development 


Remember: Think in an integrative manner 


Here are some useful illustrations of integrative thinking, as a final note. 

The British Computer Society’s POPIT™ model (as adapted in Figure 6.10) indicates how the project manager needs to 
continually think integratively and holistically about how the project impacts on the organisation, people, information 
flows and the technology that enables the information flow. 


https://www.saiglobal.com 

www .standards.org.au/Pages/default.aspx 
https://www.pmi.org/learning/library/integrated-project-management-organization-6443 
https://www.iso.org/standard/43170.html 

https://www.iso.org/standard/65694.html 


Project charter Integrated Project Management Plan Subsidiary plans 
(PMP) 
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Review questions 


What are the triple constraints? 

What are the extended seven constraints, and why are they important to project integration management? 
What are important considerations in designing a project approach? 

What are the components of an Integrated Project Management Plan? 

Why is deliverable design important? 

What is the importance of having a project charter? 

Why is integrated change control essential in the management of change requests? 

. Provide six techniques (with examples) of sharing project knowledge (and information). 


oO Or An awns 


Why are lessons-learned important to a project during, as well as after, project completion? 





> 
[=] 


. What is project governance and why is it considered at project initiation? 


= 


Complete the change requests template for change requests you have recently encountered on a project, or 
hypothetically request a change to your group project and capture this request in the template. 


N 


Using the change control process (as depicted in 
Figure 7.19 in Chapter 7), design a change control process for you own organisation/project, or create a change control 
process that would be applicable to your group project. 


bee 


Utilising the information in Figure 6.5 Deliverable design, review your group project’s deliverables and make any 
adjustments as necessary. For example, did you only include deliverables at the end of project? Did you include 
deliverables in the initiation and planning of the project? Be prepared to share your amendments to the inclusion of 
deliverables with the wider class. 


> 


For a project you have worked on recently, create a Lessons-Learned Register at project initiation. Ensure you consider 
both positive and negative lessons, and remember to include how you addressed these lessons in your project. 


Case 


Josh, who is the project manager fora local charity based in Sydney (Australia), is in the process of establishing 

the project’s governance requirements. The project is concerned with the introduction of a new patient registration 
system and technological innovations for tracking patients diagnosed with memory loss. 

It is early in the Planning stage of the project: an appropriate time to consider such matters. Josh has recently met 
with Sonya, the PMO Manager. Sonya had outlined the company’s project management guidelines to Josh. Sonya 
had also issued Josh with two policy documents: ‘Project Change Management’ and ‘issue Management in Projects’. 
Josh took the documents and has started to draft the governance section of the scope document in preperation for 
the commencement of further planning. 


1. Identify a minimum of three industry-specific examples that would be applicable to such a project, using resources 
located at https://www.saiglobal.com. 

2. Outline the project’s governance controls, indicating what aspects of governance may not have been identified by 
Josh. 

3. For the Project Change Management’ document, using a flowchart, outline the steps taken in the management of 
project change requests. 
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Learning elements | 


7A 





Understand the importance of scoping a project and how this defines what the 
project is to achieve, in what timeframe, and at what cost. 


Develop a comprehensive scope document and understand some of the practical 
techniques that can be applied in developing the content for the scope document. 


Be aware of the basic process of requirements management and how this supports 
the project team in capturing requirements from the business. 


Understand how the Scope Management Plan differs from the scope document 
and define and establish a process for change management in the project 
environment. | 








In this chapter 


= 7.1 Introduction 


m 7.2 Step 1: Defining the project scope 


7.3 Step 2: Capturing requirements 


m= 7.4 Step 3: Creating the work breakdown structure (WBS) 


7.5 Step 4: Integrating the WBS with the organisation 
7.6 Step 5: Estimating—moving towards a draft budget and schedule 
7.7 The Scope Management Plan 





7.8 Change request management 


7.9 Scrum/Agile considerations 





Summary 
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7.1 INTRODUCTION 


One of the most critical (and often one of the most difficult) activities within a project life cycle 
involves being able to successfully define the many and varied aspects of a project at its outset. This 
is because the project manager and the project team often start out with only minimal information 
(typically a partial Business Case), have only a limited stakeholder network and have only a broad 
idea of the task to be undertaken. 

The early stages of developing an outline serve to ensure that all subsequent project tasks are 
identified and that participants of the project have an understanding of ‘what is to be done’. Once the 
outline and its details are defined, an integrated information system can be developed to schedule work 
and allocate budgets (discussed in later chapters). This process of scoping a project from inception 
through to approval prior to the Executing stage is discussed in detail within this chapter. Once the 
scope baseline is established, this information can be later used for control, as the project moves from 
the Planning stage to the Executing stage. The chapter concludes with a discussion on how the project 
scope is verified in the Closing stage of the project, to ensure that what was planned and agreed in the 
scope document (plus any approved change requests) was delivered to the customer's expectations. 

Before venturing into a detailed discussion about the development of the project scope document, 
let’s first take a look at some commonly used techniques that can help to explore and define a project's 
parameters. Frequently used terminology (which is in alignment with PMI's Project Management Body 
of Knowledge (PMBOk)) is also introduced. 


E The project charter: The project charter is a summary document, which in most cases provides 
a formal agreement of the project between the project sponsor (the business) and the project 
manager. In some organisations, the project charter provides the go-ahead for the project, 
whereas in others the go-ahead will be as a result of the project manager having sought and 
obtained agreement on the wider scope of the project. Either way, the project charter is a formal, 
approved document that provides a high-level perspective of the key attributes of the project’s 
scope. 


E Scope Management Plan: The Scope Management Plan captures the more static processes 
and governance aspects of how the project scope is to be managed and approved. The change 
control process is also formalised within the Scope Management Plan (if not available from the 
PMO). This plan will be followed throughout the project (from the Initiating stage through to the 
Closing stage) for all changes requested to the scope of the project (no matter how seemingly 
insignificant). 


E Scope document: The project’s scope document defines the full and complete picture of the 
scope of work to be undertaken. The scope document is taken forward to the Planning stage 
of the project life cycle and the project manager must be cognisant of the levels of detail and 
resources (people and financial) that the business has agreed to commit to the actual scoping of 
the project. The scope document always needs to be approved by relevant. stakeholders and/or 
the project steering committee before proceeding into the detailed planning of the project and the 
development of the Project Management Plan and its subsidiary plans. 


E Work breakdown structure (WBS): The WBS provides a whole-of-project perspective on the 
activities and tasks that have to be carried out in order to deliver the defined deliverables of the 
project and therefore the product, service or result being developed by the project. 


a Estimating artefacts: In order to arrive at time, cost and resource estimates for the project, 
an estimation of the required activities and work packages within the WBS will need to be 
undertaken. The resultant estimates will be filed within the project library and developed further 
in the Planning stage of the project. Remember: There is a general industry understanding 
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that projects (during their Initiating stage) should be estimated within an accuracy of 

+/— 30-40%. In comparison, note that at the end of the project Planning stage, this will typically 
be within an accuracy of +/— 5-10%. So, from the project charter to scope through to the Project 
Management Plan, the level of accuracy will improve from around 40% to within +/— 5%. 


E Technical/product requirements: As well as documents that support the management of the 
project, numerous content-specific artefacts will be generated during all stages of the project. 
These could include detailed technical specifications on part or all of the products and/ 
or services that are being produced by the project. More typically these are referred to as 
‘requirements’. This chapter will take a more indepth look at the types of requirements and the 
process of requirements management. Figure 7.1 illustrates the flow of information as it will 
occur through this chapter regarding the ‘typical’ steps involved in ascertaining the scope of 
a project. 


Before detailing the process of scopingout a project, it is important to understand the differences 
between ‘product scope’ and ‘project scope’. 


E The product scope is all the features and functions expected from the resulting product, service 
or result. For example, a house build might have requirements around the layout of rooms, colour 
and quality of finishes; these are all specific to the product. 


Em The project scope includes all the activities that must be performed to deliver the product 
(service or result). For example, there may be a requirement that the customer attend a design 
centre to select all the internal and external finishes of the house. 


This chapter's discussion on scope adopts the assumption that project scope includes the necessary 
features and functions of the product in all aspects of project documents produced: from the scope 
statement and the WBS, through to all other parts of the Project Management Plan, subsidiary plans 
and associated artefacts. 

For example, the project manager may have defined a WBS deliverable named ‘painted walls’ with 
an activity, ‘paint interior walls’; this activity would be a quality standard for ‘painting’, which would 
include the customer's colour choice of paint for each room. The activity ‘paint interior walls’ is a 
project scope concern, whereas the ‘colour choice’ is product scope. This concept will be outlined 
further in future sections of this chapter. 


7.2 STEP 1: DEFINING THE PROJECT SCOPE 


Defining the project scope sets the stage for developing a more detailed Project Management Plan 
in the Planning stage. Project scope is a definition of the end result, or vision, of your project. The 
primary purpose of project scope is to define (as clearly as possible) the deliverable(s) of the project. 
Despite how fundamental and essential defining scope is, this process is frequently overlooked by 
business leaders in well-managed large corporations as well as in well-managed small- to medium- 
sized enterprises. 

Research clearly shows that a poorly defined scope is one of the most frequently mentioned 
reasons for project failure. In a study involving more than 1400 project managers in the United States 
and Canada, Gobeli & Larson (1990) found that approximately 5@ per cent of planning problems 
related to an unclear definition of scope and goals. This and other studies suggest a strong correlation 
between project success and clear scope definition. The scope document directs customer and project 
participants’ focus on the project's purpose throughout the life of the project and should be continually 
verified as the project progresses. The scope must be controlled for changes (or variations) to the 
scope of the project, throughout the life of the project. 
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ing a project 


Figure 714 Typical steps involved in sco 


Project governance sits across the project and is established within each of the 
management plans, described in Chapters 7 9, 10, 12-18 
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The scope should be developed under the direction of the 
project manager (with the inclusion of the project sponsor 
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Table 74 Typical project scope document contents 


il Project background 

and customer). The project manager is responsible for seeing 2 Project approach 
that there is agreement with the sponsor and customer on 3. Project benefits/dis-benefits 
project objectives, deliverables (at each stage of the project), 4. Strategic alignment 
technical requirements and so forth. Forexample, a deliverable 5, Impact if not approved 
in the early stages might be ‘develop specifications’; for the 6. Dependencies 
second stage, ‘three prototypes for production; for the third, 7. Project organisational structure 
‘of sufficient quantity to introduce to market’; and finally, 8. Stakeholders 
‘marketing promotion and training! a eee ee 

Your project scope document is a document that will be OM Deliverables 
published and used by the project sponsor, customer and 11. __ Inclusions/exclusions (in scope/out of scope) 
project team for planning and measuring project success. 42 Constraints 
‘Scope’ describes what is expected to be delivered to the 13. Assumptions 
customer(s) when the project is complete. The project scope 14. Technical requirements (including quality considerations) 
should define the results that. are to be achieved in specific, 15. Risk analysis 
tangible and measurable terms. The project manager should 16. Overall project timeline and milestones 
leave no stone unturned or any grey areas and must clarify 17. Overall project cost and funding sources 
details. In today's project environment, assumptions are no UG ROT EIMSCISITEM CEES pee 
excuse for non-delivery of product, service or result. E ESen 

20. Approvals and version control 


7.2.1 Typical project scope contents 


Source: @ 2018 Dr Neil Pearson 


Project scope is the keystone that interlocks all the elements of a project's requirements. To ensure that 

the scope definition is complete, you may wish to use a checklist, such as the one shown in Table 7.1. 
Although this list appears extensive, itis relevant to projects of all sizes, risk and complexity. If due 

diligence is not paid to define, document and agree on these aspects, a project would be considered to 


be poorly scoped (with associated potential repercussions). The authors’ top 2@ items to include ina 
generic scope document are outlined in the following pages (each item has been supported by a short 


definition, for clarity). 


1. Project background: Provides a general background to the project as to why it is taking place and 
the situation that led up to the project being required. This is the ‘story’ behind the project coming 
into being. This provides a very useful narrative to any readers outside of the project by setting 


the scene of the project. 


2. Project approach: This provides detail on how the project will be undertaken: for example, 
whether there will be a staged or phased approach; whether the project will fellow industry 
or best-practice methodologies (such as a software development life cycle (SDLC) approach); 
how the project will be approached within the organisational culture; and how the project will 
leverage the iterative planning aspects of project planning (as defined in Chapter 2 under ‘An 


introduction to PMBOK’). 


3. 


Project benefits: These should have been captured in the Business Case that kicked off the request to 
initiate the project. The project manager needs to ascertain the accuracy of these benefits and define 
which benefits will be delivered by the project, and which will be enabled by the realisation of the 
project (some benefits of the project defined within the Business Case may only be realised after the 
project has completed, during business as usual (BaU) operations). Benefits should be measurable 
(quantifiable) where possible, but will undoubtedly be a mix of both tangible and intangible benefits. 
The project manager should also consider the project's dis-benefits. Dis-benefits are ‘expected 
undesirable outcomes’. An example of a dis-benefit is the loss of value of a person or department 
arising from the project; the person or department would be termed the dis-beneficiary. 
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a) 


zal 


Strategic alignment: The project manager provides details of the alignment of the project to 
the department’s Business Plan, or the organisation's strategy; it captures which (if any) key 
performance indicators (KPIs) will be improved by implementing the project. If the project is being 
carried out for an external customer, the project manager will have to consider whose alignment is 
stated here: the organisation's perspective or the customer's raison d'être? (refer Chapter 4). 


Impact if not approved: By scoping the project, the project manager will gain a good understanding 
of the impact on the business if the project is not approved. The reasons behind the decision not to 
approve the project should always be documented so the sponsor, customer and business have a 
clear understanding of the consequences to the business if the project does not go ahead. 


Dependencies: The project manager is responsible for determining whether the project is 
dependent upon the completion of any other projects or activities in the company; for example, 
an upstream project has to be completed before activities in this project can be executed. Also, a 
review of which projects or activities in the company are dependent on this project completing 
should be undertaken (often referred to as ‘downstream’ projects). 


Project organisational structure: This illustrates the structure and reporting lines of all personnel 
identified to be involved in the project and whether these reporting lines are matrix (dottedline) 
or direct (solid4ine). Recall that Chapter 5 extensively covered the various different types of 
reporting structures. Providing those who are reviewing the scope with a ‘visual’ of the project's 
organisational structure helps them to see (at a high-level indication) the size of the human 
resource commitment that is being made to the project. 


Key stakeholders: Although the Stakeholder Matrix may be initiated during the scoping of the 
project, at minimum, the scope document should contain a list of the key stakeholders involved in 
the project. It should set out what their individual role is, what you (as project manager) want from 
them, and conversely, what they want from the project. Their relative power and interest in the 
project should also be indicated. (Remember: A stakeholder is anyone who has an interest in the 
project or is impacted by the project.) Refer Chapter 15 for a detailed discussion on stakeholders. 


Project objectives: What are the objectives of the project? (Reflect back to the SMARTA acronym 
introduced in Table 4.1 in Chapter 4.) By applying SMARTA to the project's objectives, the project 
manager ensures that each individual written objective is Specific, Measurable, Assignable, 
Realistic, Timebound and Agreed. The project’s objective answers the questions of ‘what, when 
and how much?’ In today’s project management environment, it is also important to define 

the critical success factors (CSFs) of the project. This means thinking holistically about what 
factors provide a picture of the project’s success and what must be achieved for this to occur. An 
example of an objective versus a CSF is given below: 


Objective: Achieve fresh supplies from ‘farm to CSF: Sustain successful relationships with local suppliers 
customer’ in 24 hours for 75 per cent of organic and produce a new product line for health-conscious 
fresh produce we handle. consumers. 


10. Deliverables: Deliverables are often categorised into two types: outputs—usually associated with 


the tangible (physical) aspects that the project is to deliver (e.g. training manuals, a redesigned 
phone, a finance system server and software); and outcomes—associated with changes in 
behaviours, (e.g. the new finance system is adopted by all company users and people are confident 
in using it—providing benefits to the organisation in the faster recovery of monies owed). 


11. Inclusions (in-scope)/exclusions (out-of-scope): Most project managers are very adept at 


documenting what is included within the project. However, what about, what is specifically not 
included within the scope of the project? If out-of-scope items are not documented, this can lead 
to situations where undocumented assumptions arise later on in the project: for example, where 
one party assumes these were included in the scope of the project (typically the customer) 


while the other party makes the assumption that 
they were not included in the scope of the project 
(typically the project manager). (Note: Some 
organisations, including those using Lean Six 
Sigma, call this an ‘is’ and ‘isnot’ analysis—i.e. 
what is in scope and what is not in scope.) 

A commonly used tool for understanding scope is 

the context diagram, sometimes referred to as a 
Business Use Case. A context diagram indicates scope 
by indicating the actors (users, IT system or group) 
and their highlevel interaction with the product, 
service or result. For example, an actor ‘employee’ in 
an HR kiosk development project could want to ‘lodge 
a leave request’ or ‘query remaining leave’. These are 
activities that are in scope of the project. 

Figure 7.2 is a partial context diagram for a taxi 
and driver registration system. 

A popular variant to the context diagram is the 


rich picture. This is more informal in nature. The 
rich picture captures essential considerations for 
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Taxi owner 
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inclusion in the scope of the system being considered. Figure 7.3 illustrates a rich picture for how 


a patient is currently admitted into a care home. The thought bubbles on the diagram indicate the 


importance of building some rich pictures—these indicate the feelings/emotions of the people 


(actors) involved in the process. Rich pictures can provide insights into the current system of 


events that are taking place or future system of events that are to be considered. They provide an 


ideal way of engaging handson with your key subject matter experts (SMEs). 
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12. 


Constraints: This refers to documented conditions that are known to have a constraining effect 
on the project. They may be financial or related to the conditions in which the project is taking 
place (e.g. there is resource scarcity). Any constraints raised should be assessed for hidden risks. 


13. Assumptions: What are the known (confirmed) assumptions for the project? Assumption 


14. 


15. 


16. 


17. 


18. 


statements are accepted as ‘true without proof’. Assumptions are circumstances and/or activities 
that need to occur in order for the project to be successful, but that are outside of the control 

of the project team. For example, an assumption for a large construction project could be ‘no 
shortage or cost increases in the supply of cement to the project’. Any assumptions raised should 
also be assessed for hidden risks. 


Technical requirements (including quality considerations ): Here, the scope would (at a high 
level) seek to document the technical aspects of the product and/or service being produced (e.g. 
the known technical requirements for a large-bore water pump). These requirements would 

also form the basis of planning for the quality assurance aspects of the product/service being 
produced. 


Risk analysis: The project sponsor is often a good source for information about highlevel risks 
to the project from a business perspective. The customer may additionally have some concerns 
they want to articulate at project outset. However, ultimately, the responsibility of identifying 
high-level risks during project scoping falls to the project manager: they must ensure not only 
that high-level risks are identified, but that the probability/likelihood (the chance) of such risks 
occurring and their impact/consequence (the effects if the risk occurs) are also analysed. (Note: 
Project risk management is the topic of Chapter 17.) 


Overall project timeline and milestones: The WBS will be started as part of the development 

of the scope document. This will inform (through the estimating activities) the overall project 
timeline, milestones, assumptions and end-date for the project. A milestone is a significant event 
in a project and occurs at a point in time. The milestone schedule shows only major segments 

of work; it represents first, ‘rough-cut’ estimates of time, cost and resources for the project. The 
milestone schedule is built using the deliverables and the WBS as a platform to identify major 
segments of work and an end-date. Milestones should be natural, important control points in the 
project. Milestones should be easy for all project participants to recognise. The timeline presented 
within the scope document assists in clarifying understanding of the major milestones with those 
responsible for scope approvals. The timeline in scoping may also be supported with a highlevel 
project schedule, usually in the form of a Gantt chart, which provides a level of detail to those 
interested reading beyond the timeline (refer to Chapter 9). 


Overall project cost and funding sources: The same techniques can be applied as per point 16 
(above), but with the goal of arriving at an overall project estimate for costs. It is also useful to 
consider the identification and approval (with the project scope document) of any long lead 
time items and/or large capital items. Discussed in Chapter 18, these items may impact points 16 
and 17 and may require special approvals, earlier than planned in the project life cycle. Note: In 
estimating costs, the project manager will also be considering the resource commitment (as this 
will have to be estimated from both a cost and schedule perspective). 


Organisational change impact: Most projects deal with change from one state (the ‘asis’ state) 
to another planned state (the ‘to-be’ state, or planned outcome of the project). The project scope 
document should contain a review of the change impact to the business of the project. Some of 
the questions the project manager needs to address during this early stage of the project include 
whether the business is ready for the change proposed by the project, what other changes are 
occurring at the same time that might need coordinating with this project, and whether the 
project needs to employ the services of a specialist change manager. See ‘Managing the impact of 
change on stakeholders’ in Chapter 15 for more information. 
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19. A review of previous project(s) lessons-learned: The scope document. should capture the sources 
and lessons-learned from previous projects that are relevant to this project, both for projects 
within and outside the organisation. This helps to ensure that. mistakes of the past are considered 
when designing the project in-hand and are not repeated. 


20. Approvals and version control: All project documents should have version and distribution 
control information on their front page. This ensures that when the scope document is reviewed, 
all stakeholders involved in the review are using the same version of the document. 


Note: Often valuable meeting time is lost in trying to ascertain which versions of the documents 
are around a meeting table. As part of the governance process (gated life cycle) the project scope 
document should be reviewed extensively by all key stakeholders and by the project sponsor and 
customer, with appropriate sign-offs obtained before the project moves into the Planning stage. 


Source: ® 2018 Dr Neil Pearson 


Scoping a project should not be considered a ‘tick-and-flick’ activity. It is a serious endeavour to ensure 
that all parties are in agreement on what is to be achieved by the project, how long it will take, at what cost 
and what will be delivered at the end of the project. The scope document is a living document that travels 
with the project. After all, the project manager needs a scope baseline document that has been agreed on 
and approved, against which changes to scope can be managed (e.g. to prevent scope creep). Figure 7.4 


aptly depicts the type of mismatch in understanding that can occur if a project is not correctly scoped. 





Create your own cartoon at www projectcartoon.com 
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Source: The Project Cartoon 2016, ‘How projects really work’, available at wwwprojectcartoon.com/cartoon/2 
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The authors’ list of top 20 items for inclusion in a scope document offers a generic list of potential 
scope inclusions. It is generic only, since different industries and companies will develop their own 
unique checklists and templates to fit their specific business needs and project types. Many companies 
engaged in contract work refer to the Scope document as a scope statement or a statement of work 
(SOW). Other organisations use the term project charter. However, the term ‘project charter’ has 
emerged to have a special meaning in the world of project management, referring to a document that 
authorises the project manager to initiate and lead the project. This document is often issued by upper 
management and provides the project manager with written authority to use organisational resources 
for project activities. Often, the charter will include a brief scope description, as well as such items as 
risk, customer needs, spending limits, and even team composition, but it does not provide the level of 
detail that the scope document captures. 

Many projects suffer from scope creep, which is the tendency for the project’s scope to expand 
(change) over time (usually because of the customer’s changing requirements, specifications and 
priorities). Scope creep can be reduced by not only having a well-written scope document, but also 
by having a process to manage project changes, as and when they occur. A scope statement that 
is too broad is an invitation for scope creep. Scope creep can have a positive or negative effect on 
the project, but in most cases it means added costs and possible delays. Changes in requirements, 
specifications and priorities frequently result in cost overruns and delays. Take a look at the two 
examples provided in Snapshot from Practice: Scope creep. 

If the project’s scope needs to change, it is critical to have a sound change control process in place 
to record changes and keep a log of the status of all changes. The process of managing scope change 
is discussed in detail later in this chapter. 


7.2.2 Establishing project priorities: The triple constraints 

The ultimate success of a project is traditionally based on meeting and/or exceeding the expectations 
of the customer and/or upper management in terms of cost (budget), time (schedule) and performance 
(scope) of the project. The interrelationship among these criteria is often referred to as the triple 


SNAPSHOT FROM PRACTICE Scope creep 





train wrecks such as Queensland Health's A$1.2 billion 
payroll failure are preventable, but do require foresight, 
skilled senior staff and, above all else, good planning. ACS 
president, Nick Tate, following the release of an audit by 
KPMG into Queensland Health's payroll system, is quoted: 
‘At some point, the scope [of the project] changed quite 
substantially, or an understanding of the scope changed 
during the course of the project, and it appeared that the 
overall project leadership therefore changed’. As a result 
of those changes, Tate said it appeared there was an 


One of the largest water providers in Australia, Sydney 
Water Corporation established a project to introduce an 
automated billing and customer information system. The 
project was, however, aborted part way through after 
the corporation had spent in excess of A$61 million. 
The cause of the project's failure was attributed to poor 
planning and poor requirements specifications. This led to 
a stream of endless change requests by stakeholders and 
customers, adding costs and delays to the project and 
forming a prime example of scope creep. 


In 2010, the Queensland Health Service’s new payroll 
and rostering system went live (to approximately 78 000 
staff members). The system did not function as intended 
and many employees reported being either underpaid, 
overpaid or not paid at all (i.e. not on time). On 13 December 
2012 the Executive Council appointed a commission of 
enquiry to investigate what had gone wrong and why. As 
reported in C/O magazine (McDonald 2012) IT project 


inadeguate number of people working on the project who 
actually understood it. He said personnel on the project 
also did not appear to understand how to apply project 
management techniques. 








Source: McBonald S 2012, ‘QLD Health payrell: IT “train wrecks” preventable’, 
CIO, 7 June, https://www.cio.com.au/article/426920/gld_health_payrell_it_ 
train_wrecks_preventable, accessed February 2018. 
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constraints (see Figure 7.5). For example, sometimes it is necessary to 
compromise the performance and scope of the project to get the project 
done quickly or less expensively. Often the longer a project takes, the 
more expensive it becomes. However, a positive correlation between 
cost and schedule may not always be true. Other times, project costs 
can be reduced by using cheaper, less efficient labour or equipment 


ure 7.5 The triple cons 





that extends the duration of the project. Likewise, project managers 
are often forced to expedite or crash certain key activities by adding 


additional labour, thereby raising the original cost of the project. rae me 
It is important to recognise the significance of quality being at the 
centre of the triple constraints. In light of other dimensions changing INS SOc Seti elses omni arGhirige OY 
ji f 5 4 5 Seven preject constraints around the seven constraints 
(scope, cost and time), the project manager is tasked with ensuring that are now more frequently considered 


that quality does not suffer in light of other changes. This is indeed a 
difficult balancing act at the best of times. One of the primary jobs of 
a project manager is to manage the trade-offs between time, cost and performance (scope). To do 
so, a project manager must define and understand the nature of the priorities of the project. They 
need to have a candid discussion with the project sponsor, customer and management to establish 
the relative importance of each criterion. For example, what happens when the customer keeps 
adding requirements? Or, if midway through the project, a trade-off must be made between cost and 
speed—which criterion has priority? 

One technique found in practice that is useful for this purpose involves completing a Priority 
Matrix for the project, to identify which criterion is constrained, which should be enhanced and which 
can be accepted: 


E Constrain. The original parameter is fixed. The project must meet the completion date, 
specifications, and scope of the project or budget. 


E Enhance. Given the scope of the project, which criterion should be optimised? In the case of time 
and cost, this usually means taking advantage of opportunities to either reduce costs or shorten the 
schedule. Conversely, with regard to performance, enhancing means adding value to the project. 


@ Accept. For which criterion is it tolerable not to meet the original parameters? When trade-offs 
have to be made, is it permissible for the schedule to slip, to reduce the scope and performance of 
the project, or to go over budget? 


Figure 7.6 displays a Priority Matrix for the development of a new IoT (internet of things) device. 
Because time to market is important to sales, the project manager is instructed to take advantage of 
every opportunity to reduce completion time. In doing so, going over budget is acceptable, though 
not desirable. At the same time, the original performance specifications for the device, as well as 
reliability standards, cannot be compromised. 

Priorities vary from project to project. For example, for many Figure 7.6 Project Priority Matri 
software projects, time to market is critical, and companies like 
Microsoft, may defer original scope requirements to later versions, in 
order to get to the market first. Alternatively, for special event projects 
(e.g. conferences, sports events, tournaments) time is constrained once Constrain @ 
the date has been announced, and if the budget is tight, the project 
manager will compromise the scope of the project in order to complete Ehana © 
the project on time. 





Time Performance Cost 








Some would argue that all three criteria are always constrained and 
that. good project managers should seek to optimise each criterion. If 
everything goes well on a project and no major problems or setbacks 
are encountered, their argument may be valid. However, this situation is 


Accept @ 
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SNAPSHOT FROM PRACTICE Whether a small or large project, scope is 


important—Relationships Australia Queensland 





Scope is key for gaining an agreement between all parties 
involved in the project. On a recent ISO: 9001 project 
that one of the authors was involved in, a shortterm 
contract to deliver specific components of a larger ISO 
project had to be scoped before a contract value could 
be placed on the project. The sponsor, the operations 
manager and the quality manager were adopting a 
ightPRINCE2 approach towards the project and they 
therefore set about establishing the scope of the project 
or, as referred to in PRINCE2, the Project Initiation 
Document or PID). The scoping activities included the 
author in some pre-contract work, to establish exactly 
what was required from the project. Buy-in from all 
parties significantly assisted the process of clarifying 
and focusing the project from the outset. Although the 
project was to run for only six weeks, it was important that 
very close attention was paid to establishing its scope. 
The non-negotiable constraints for the project were time 
the project had a fixed duration of six weeks) and cost; 
he scope was subject to a number of constraints and 
assumptions, as illustrated in Table 7.2. 








Table 7.2 Managing the triple constraints 


Time Scope Cost 
(Performance) 
Constrain oO @ 
Enhance 
Accept O 


Assumptions piaced around scope (performance) constraints 
included statements about: 


m accessibility to resources, the executive team 
{including the CEO) and other senior management 


m accessibility to key subject matter experts (SMEs) in 
the business 


m identification and on-boarding of two key supporting 
business analysts to shadow the author, so that active 
knowledge transfer could take place. 


Based on the scope, some specific deliverables (both 
output and outcome) were defined, as indicated in Table 7.3. 
What this table demonstrates is that all parties knew exactly 
the scope of the project agreements, and ‘being on the 
same page’ took place from the outset, before contracts 
were signed. 


Table 7.3 Scope outputs and outcomes 


Deliverables: Outputs 


m Level 0 ‘process zone’—defined for all processes and 
nominated process owners were agreed to and assigned to 
each process. 

m Process workshop for executive team x 2. 

m Process workshop for each executive team member and 
nominated representatives. 

m Process Policy developed and communicated. 

m Continuous Improvement (CI) Policy and Cl register 
development, communication and application. 

m Business analysis process mapping guidelines, Requirements 
Gathering Template, and Measure Definition Template 
developed and applied. 

m ‘As-is’ process for service area, translated into business 
process model and notation (BPMN) (with business analyst 
(BA) resources). 

m BA position description agreed with human resources and 
BA role(s) recruited (from internal resource pool). Internal 
resources trained in business analysis skills and process 
modelling skills. 

m Selection and implementation of organisation process 
Management technology, to support ongoing mapping of all 
organisational processes (for ISO accreditation). 


Deliverables: Outcomes 


m Holistic process understanding by the executive team and 
directs: Process Policy is agreed and understood. 

m Process owner role description is agreed and signed up to. 

m Process owners are owning the nominated processes and 
starting to engage in mapping (at a high-level) the Level 1 
process maps. 

m The process owners are gathering continuous improvement 
requests and are prioritising these in a register for review as a 
process owner team. 

m BArole established and coached through development of the 
first processes. 

m Process owners generally understand the business process 
notation, and nominated representatives have the ability to 
develop basic processes. 

m Communication of the role of processes in the organisation, 
the links to quality and the general process notation to the 
whole of the business are understood. 


As the sponsor had a solid knowledge of a project 
management approach, constructive and robust discussions 
around the scope of the project took place. Whether a 
project is small or large, the importance of scoping cannot 
be overstated. As a side note, the six-week project did 
produce the defined deliverables, on time, to budget 
and within the resource constraint—the company worked 
extremely hard to make the resources available at the 
correct time. 
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rare, and project managers are often forced to make tough decisions that benefit one criterion while 
compromising the other two. The purpose of this exercise is to define and agree on what the priorities 
and constraints of the project are, so that when push comes to shove, the right decisions can be made. 

There are likely to be natural limits to the extent managers can constrain, optimise or accept any 
one criterion however. It may be acceptable for the project to slip one month behind schedule but no 
further, or to exceed the planned budget. Likewise, it may be desirable to finish a project a month 
early, but after that, cost conservation should be the primary goal. Some project managers document 
these limits as part of creating the Priority Matrix. 

Insummary, developing a decision Priority Matrix for a project before the project begins isa useful 
exercise. It provides a forum for clearly establishing priorities with customers and top management, 
so as to create shared expectations and avoid misunderstandings. The priority information is 
essential to the planning process, where adjustments can be made in the scope, schedule and budget 
allocation. Finally, the matrix can be useful throughout the project to check priorities in light of 
pending changes. 

Something to be conscious of is the fact that priorities may change during the course of a project. 
For example, the customer may suddenly need the project completed one month sooner, or new 
directives from top management may emphasise cost-saving initiatives. The project manager therefore 
needs to be vigilant so they can anticipate and confirm changes in priorities and make appropriate 
adjustments. 


a 


7.3 STEP 2: CAPTURING REQUIREMENTS 


The whole process and approach of capturing requirements within a project environment. (whether 
a software, construction or service project) has become more structured and techniques that have 
predominantly evolved from the world of software engineering are increasingly being used across 
all industries and projects. ‘Requirements’ originate from the Initiating, Planning (and even from the 
Executing) stages of a project. The challenge lies in accurately collecting and analysing requirements 
to ensure the product, service or end result can be later validated to ensure it meets what was expected 
(and defined in the original requirements). 

Many projects fail because of inadequate requirements gathering and poorly defined 
requirements. A requirement is a criteria or condition (business rule), or capability or product, 
service or result required to be captured (elicited), documented and validated in order that the 
project can ultimately deliver it. If a complete set of requirements is not captured, documented 
and validated, the chances are that the project will not deliver what the customer requires. It is the 
role of the project manager to guide the collection of these from a product scope perspective (most 
probably supervising a team of engineers of business analysts to do so). From a project scope 
perspective, it is the project manager's responsibility to ensure this is carried out ina complete and 
comprehensive manner. 

Figure 7.7 illustrates the requirements management process thatis adopted in this text. This process 
was built based on industry experience—the process illustrated does, however, adopt elements from 
both the PMI's Requirements Management: A Practice Guide (PMI 2016) and the British Computer 
Society's Business Analysis Practice (BCS 2014). 

Lets examine the stages of this requirements management process and how these relate to 
activities not only in scoping the project but as ongoing activities throughout the project life cycle. 
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Figure 7.7 Requirements management a 


Requirements Requirements Requirements Requirements Requirements 
Planning elicitation analysis validation verification 








Requirements documentation and management 







Monitor and control 


Source: © 2018 Dr Neil Pearson 


E Requirements planning: As the project kicks off and the project team is formed, the project 
manager must consider how requirements are to be managed, including: 


— establishing the process for requirements management, as illustrated in Figure 7.7 
— ensuring the correct tools and training to support the process are actioned 


— developing the Requirements Management Plan, and setting out the process, tools and techniques 
used to support the management of requirements in the project environment, if not available from 
other areas of the business 


— agreeing with the project team on how requirements will be socialised with other stakeholders, via 
a business requirements specification document or other means 


— agreeing with the business a protocol for the prioritisation of requirements (refer to MoSCoW, in 
Chapter 3). 


E Requirements elicitation: During the Planning stage of the project life cycle the project team 
(including the project manager) will generate potentially hundreds of requirements. These will 
be captured in various working documents, which will typically cause problems in maintaining 
requirements. Therefore, a suitable tool should be made available to assist with capturing the 
requirements in a consistent manner. 


A basic tool could be as simple as setting up a Microsoft® Excel spreadsheet, which will then 
allow for the analysis of requirements (i.e. de-duplicating, creating atomic (singular) 
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requirements, and reuse of requirements (e.g. within different business rules). A simple snapshot 
from this type of spreadsheet is illustrated in Figure 7.8, often referred to as a Requirements 
Traceability Matrix. 


®, 


Requirements elicitation is an important step that necessitates active engagement with the 
project's stakeholders to extract and capture requirements. Common techniques used in this process 


include: 


— Observation: A project team member observes a stakeholder when they are carrying out tasks and 
uses questions to clarify information about the tasks. The observer might have to visit different em- 
ployees carrying out the task at different times, to gain a true understanding of the task and future 
requirements to be considered by the project. 


— Interviews: A project team member interviews one or multiple stakeholders to ascertain 
requirements. Requirements might have to be cross-referenced to ensure a unique set of 
requirements are generated. 


Figure 7.8 Requirements Traceability Matrix 
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guidelines and 
branding. 























Note: This is a cutdown matrix; however, it does indicate requirement traceability backwards to the originator of the requirement 
and requirement traceability forwards to the team member assigned the WBS item, and forward again to the module the 
requirement would be released in 
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Fecus greups: A group of stakeholders is brought together and discussions are focused around a 
particular subject in order to discuss, negotiate and ultimately agree ona set of requirements. A 
number of focus group sessions may need to be carried out to fully explore and define the require- 
ments to the required level. 


Werksheps: Workshops can be run in many different ways (from brainstorming sessions to fish- 
bowl sessions). They can be (especially in the early days) quite creative and exploratory in nature. 
The idea is to bring a group of people together to gain agreement on a set of requirements to be 
taken forward by the project. 


Scenaries: Getting stakeholders to tallk/act through various scenarios to explain/demonstrate 
how they would use a particular product or service. The arising scenarios would be captured and 
requirements would subsequently be extracted for verification later on. 


Surveys/questiennaires: Typically used for large, geographically dispersed groups. Development of 
surveys is a specialist task which will yield successful and useful results. 


= Requirements analysis: In this chapter, it has been pointed out that missing or incorrect 
requirements are cited as being one of most frequent reasons for projects that fail. This 
emphasises that not only is the whole requirements management process important, but so too 
is making sure that the ‘collected’ requirements are appropriately analysed. Analysis will include 
working out if requirements: 


don't overlap—part of one requirement appears in another requirement 


are not duplicated—total duplication of a requirement elsewhere in the project, often collected by 
different project team members 


don’t appear multiple times—split them out and make them ‘atomic’ (i.e. each requirement state- 
ment must only ‘cover’ a single requirement) 


are irrelevant—are they are required and directly relate to the problem? Otherwise why are we 
looking at them in this project? 


are feasible—technically, financially (it can be funded) and business feasible (it can be implement- 
ed in the business)? 


don't conflict—contradicting or conflicting requirements must be resolved 
are free of solutions—the business reason for why the solution is being suggested must be ascertained 


are comprehensible—use clear, plain English and avoid jargon and acronyms; and use 
concise, verb-noun, or the Agile approach, ‘As a , | want to , so that I can 


are consistent—across the whole group of requirements (i.e. requirements are defined to a 
similar level of detail) 


are unambiguous—no assumptions are made in the interpretation of a requirement 
are correct—describes something that is required to meet the objectives 
are testable—the solution can be tested to confirm the requirement has been met 


are traceable—from the requirement's source to where it was deployed (software or product 
in use by consumers) 


are prioritised—requirements with business input take on the same MoSCoW approach (as 
introduced in Chapter 3). 


Business analysts often refer to this list as requirements filters (BCS 2014) as each requirement 
is filtered through these criteria to ensure they are ‘well formed’. 


E Requirements validation: This is considered to be more of an internal process, to validate 
the requirements collected with the stakeholder (internal or external to the organisation) are 
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Complete (are what they want), Accurate, Signedoff and Testable (often referred to as CAST). 
This should mean that when the project or service is built during the Executing stage of the 
project, it meets the CAST requirements (i.e. it demonstrates the features and functions that the 
‘customer’ wants—and no more!). 


E Requirements verification: Usually occurs at certain points in a predictive project, for example, 
when a deliverable is handed over to the business, when the project reaches a particular phase or 
‘stage gate’, or at the end of the project. When any of these events occur, the product (service or 
result) will be verified against the previously agreed CAST requirements. If the deliverable does 
not meet requirements, decisions must be made about which direction this issue/shortfall needs to 


be taken in. Would, for example, rework correct the issue/shortfall that. has been identified? How 
much effort is this rework? Who is going to pay for it? 


Remember: Quality requirements generate good results for the project only when the work around 
building and developing the requirements is successfully engineered (designed) into the WBS (or 


equivalent). 


Requirements are generally classified into differing categories. Table 7.4 depicts a commonly 
encountered categorisation system (based on BCS 2014). The table also provides information about 
where in the project life cycle the category of requirement is likely to be identified and captured. 
Examples from different types of projects are given to help explain this ‘fit’. 


Table 7.4 Requirement types 


Business: General 


Business: Technical 


Solution: Functional 


Solution: Non-functional 


High-level business requirements 
related to: 

— business policies 

— legal 

— branding 

— cultural 

— language. 


Overarching technical 
requirements, related to: 
— hardware 

— software 

— interoperability. 


Any feature required by the 
business in the final solution, 
related to: 

— creation of data 

— reading/retrieval of data 

— update/maintenance of data 
— procedural requirements 

— disposal/deletion of data 

— usage of a product or service. 


Technical specifications related to: 


— performance 

— access 

— security 

— usability 

— Capacity 

— backup and recovery 

— achieving and retention 
— maintainability 

— business continuity. 


Initiating 
Planning (scoping) 
or Sprints 


Initiating, 
Planning (scoping) or Sprints 


Planning 
or Sprints 


Planning 
or Sprints 


All external (customer) interfaces must meet 
the organisation’s branding standards. 

The final product must meet product safety 
standards, as laid down by the country of 
sale (e.g. vehicle jacks must comply with 
AS/NZS 2693 Vehicle Jacks (https://www. 
productsafety.gov.au/standards/vehicle-jacks). 
The system must comply with financial 
regulations and services legislation. 


The system must produce outputs that are 
compatible with Microsoft Office 365. 

The application must operate on the 
company’s Standard Operating Environment, 
based on Apple OSX. 

The product must operate on all European 
electrical sources. 


The payroll system must ensure a full audit trail 
of all payments is maintained. 

As an events manager | want to be able to 
query all events by artist so | can answer 
customer enquiries. 

Asa user of a mobile phone | want to be able 
to record any voice call, so | can comply with 
legal requirements. 

Asa user of a building, | want to be able to 
release the front door lock from the inside of 
my apartment, so | do not have to open the 
front door lock in person. 


The payroll system must compile the pay data 
file (sent to the payroll bureau) in a compatible 
file type. 

The door release must occur within three 
seconds of being activated. 

The mobile phone network must connect calls 
within six seconds of the call being initiated. 
Only the payroll manager can access the pay 
details of executive managers. 
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7.3.1 Scrum/Agile considerations: Requirements 


Chapter 3 outlines the Scrum approach to requirements. This basically involves the product owner 
collecting and prioritising stories from the business which the development team takes a subset of 
(at the Sprint planning meeting) into the Sprint backlog for development into a ‘potentially shippable 
product’. Refer Chapter 3. 


7.4 STEP 3: CREATING THE WORK BREAKDOWN 
STRUCTURE (WBS) 


Once the scope of the project has been defined (including the identification of deliverables), the 
work of the project can be successively subdivided into smaller work elements. The outcome of this 
hierarchical decomposition process is called the work breakdown structure (WBS). Using a WBS 
helps to provide a project manager with a degree of confidence that all products and work elements to 
be integrated into the project within the current organisation have been identified and that a basis for 
control has been established. Basically, the WBS is a visual description of the project, with different 
levels of detail. It provides a well-developed description of the project and helps the project manager 
to ensure that just the right scope and nothing more and nothing less is achieved. There are occasions 
where more is delivered by gaining project efficiencies, but not at the cost of delivering the agreed 
scope baseline (the deliverables). In practice, the scope document and WBS are developed in parallel— 
as one often informs the other. 

Figure 7.9 shows major groupings that are commonly used in practice to develop a WBS. The WBS 
begins with the project as the final deliverable. Major project work deliverables are identified first, 
and then the sub-deliverables needed to accomplish the larger deliverables are defined. The process is 
repeated until the sub-deliverable detail is small enough to be accurately estimable and manageable, 
and one person/discrete group of people can be made responsible for carrying out the work. The 
lowest sub-deliverable becomes effectively the packages of work which can be allocated to project 
team members—often referred to as ‘work packages’. 


7.4.1 How WBS helps the project manager 


The WBS defines all the elements of the project in a hierarchical framework and establishes their 
association with the project. Think of the project as a large work package that is successively broken 
down into smaller work packages: the total project is the summation of all the smaller work packages. 
This hierarchical structure facilitates the evaluation of cost, time, resources and technical performance 
at all levels in the organisation over the life of the project. The WBS also provides management. with 
information appropriate to each level. 

Each item in the WBS needs a resource, time and cost estimate. With this information it is possible 
to plan the project schedule, develop the project budget and identify the resource requirements for the 
project. The WBS also serves as a framework for tracking cost and work performance later on in the 
project life cycle, during the Executing stage (discussed in Chapter 11). 

As the WBS is developed, organisational units and individuals are assigned responsibility for 
executing work packages; this integrates the work and the organisation. Note that. organisation 
breakdown structure (OBS) is discussed later in this chapter. 

The WBS provides the opportunity to ‘roll up’ (sum) the budget (the planned costs) of the smaller 
work packages into larger work elements, so performance can be later measured by organisational 
units and by work accomplishment. 

The WBS can also be used to define communication channels and assist in understanding and 
coordinating many parts of the project. The structure shows which work and organisational units 
are responsible for what. Problems can be quickly addressed and coordinated because the structure 
integrates ‘work’ and ‘responsibility’. The WBS assists the project manager to answer the question: 
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Description 


Complete project 


1 $ Project 


2 Activity Major deliverables 

3 Task Supporting deliverables 

4 Subtasks Lowest sub-deliverable Lowest management 
responsibility level 

5 Cost account* Grouping of work 





packages for 
monitoring progress 
and responsibility 


vok Work package Identifiable work 
package activities 


* This breøkalown groups work packages by type of work within # deliverable ana allows assignment of responsibility to an 
organisational unit, This extra step facilitates @ system for monitoring project progress. 


@ 2013 McGraw-Hill Education (Australia) Pty Ltd 


What must be done? Chapter 8 focuses on the questions: How long will it take? How much will it cost? 
and Who/What will do the work? 
Figure 7.10 shows a simplified WBS for the development of a new Smart Watch project. 


7.4.2 WBS development 


Refer to Figure 7.10. At the top of the chart (referred to as ‘Level 1’ in PMBOK) is ‘the project end 
item’ (i.e. a deliverable product or service). Level 2 shows a partial list of deliverables necessary for 
developing a Smart Watch. One deliverable is the ‘connectivity’ (shaded), which is made up of three 
sub-deliverables: Altimeter module, LTE cellular module and GPS module. Finally, each of these sub- 
deliverable requires work packages that will be completed by an assigned organisational unit/person. 
Each deliverable will be successively divided in this manner. Note that it is not necessary to divide all 
elements of the WBS to the same level. 

The lowest level of the WBS is called a work package. Work packages are shor t-duration tasks 
that have a definite start and stop point, consume resources, and represent a cost to the project. Each 
work package is a control point. A work package lead is responsible for seeing that the package 
is completed on time, within budget, and according to technical specifications (quality). Practice 
suggests a work package should not exceed 10 workdays (or one reporting period). If a work package 
has a duration exceeding 10 days, checkpoints or monitoring points should be established within 
the duration, say, every three to five days, so progress and problems can be identified before too 
much time has passed (and costs have been incurred). Each work package of the WBS should be as 
independent of other packages of the project as possible. 
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Figure 740 Work breakdown structure: Smart Watch example 
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SNAPSHOT FROM PRACTICE London 2012 Olympic Games 





On 27 July 2012, the London Olympic Games started. m provide sustained improvement in UK sports, pre-and 
The Olympic Delivery Authority (the Olympics’ project post-games 

client) made it clear that ‘Not starting on that day is not 
an option. The deadline is 100 per cent fixed! This was 
the mandate for both the general contractors and the 


m ensure the venues were used for something useful 
after the Games. 


information services (IS) teams. Each had to meet the Below is the initial timeline for the 201 2 Olympic event: 
schedule while contributing to the overall objectives of 2006: Set foundations 
the Olympic team. 2007: Strategic planning 

The 2012 Olympic project team objectives were to: 2008: Review all past Olympics 


2010: Operational planning 
2011: Test events 

2012: Operational readiness 
m deliver an Olympic park and related venues 2013: Close down 


m stage the 2012 Olympic and Paralympic games on 27 
July—12 August 2012 


m maximise economic, social, health and environmental Physical facilities and information services were two 
benefits for London and for the UK of the major areas that needed massive coordination 


and represented a sizeable part of the total budget. 
London 2012 was the sixth Olympic Games designed, 
built and operated by the IS infrastructure Atos Origin. 
Michele Hyron, the chief integrator responsible for the 
event's information systems, oversaw one of the biggest 
information technology projects ever. She is a seasoned 
Olympics project manager who served as IS operations 
manager in previous Olympics in Athens and Be jing. By 
examining the processes and lessons-learned from earlier 
Games, she hoped past mistakes could be avoided. For 
example, four ‘lessons’ were learned from the Beijing 
Games: 


1. Better training needed for support staff. 
2. Freezing design four months before Games. 


3. Isolating IT from the internet. 


oa 


. Better planning. 


Hyron purportedly carries over about 40 to 50 per cent 
of systems planning from one Olympics to the next, and 
then adjusts to local conditions. Hyron designed and built 
fully redundant systems for 2012 that were used for two 
years of testing of over 1000 scenarios to study how 
systems and technical personnel responded to each of 
the scenarios. Test scenarios included asecurity breach, a 
fire in a living facility, staff contracting food poisoning, and 
events that were delayed. 

Physical facilities and logistics were equally as important 
as IS infrastructure. The Olympic Delivery Authority (ODA) 
selected EDAW Consortium to design a master plan for the 
Olympic Park’s infrastructure (including utilities, waterways, 
landscape, platforms for the site, roads and bridges). A 
500-acre Olympic Park in Stratford, east London, was the 
epicentre of the Games. The Olympic Stadium housed 
the 80 000-seat coliseum as well as the aquatics centre, 
which had two pools and a diving pool. A Channel Tunne! 
Rail Link (CTRL) carried a high-speed shuttle service 
between central London and the Olympic Park in just 
seven minutes. This link also connected with the service 
to continental Europe. Transportation to the Olympics was 
supported with improved underground services. Planners 
expected to have a train arriving at the Olympic Park every 
15 seconds. There were 20 kilometres of new roads and 
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more than 30 new bridges to connect the Olympic Park 
with nearby communities. Then Prime Minister, Gordon 
Brown, estimated that nearly 30 000 workers would build 
the Olympic Park and Olympic Village. 

From the outset, cost estimating was a challenge. 
When London announced its bid for the 2012 Games, 
the estimated cost for the Games was £4 billion. By 
2007 the estimated costs had climbed to £9.325 billion. 
In mid-2009, 500 industry professionals estimated the 
costs would rise to £11.6 billion (some estimates ran as 
high as £12.6 billion). The National Audit Office study 
identified two major problems with the Olympic Games 
project: No one single individual was in charge, and there 
was no proper budget. In addition, the committee offered 
the following suggestions: (a) clarify key deliverables and 
expected costs, (b) establish a baseline for budget control, 
and (c) manage both contingency and project funds more 
rigorously. 

The Olympic Games are often referred to as ‘the 
greatest show on earth’. Although there were many 
challenges and opportunities for the project managers 
of the 2012 Olympic Games, given the success of the 
Games, the project clearly delivered its objectives. 


Source: Adapted from www.ComputerWeeklycom 


There is an important difference from start to fmish between the last work breakdown sub- 


deliverable and a work package. Typically, a work breakdown sub-deliverable includes the outcomes 
of more than one work package (providing a way of grouping tasks), from perhaps two or three 
departments. Therefore, the sub-deliverable does not have a duration of its own and does not consume 
resources or cost money directly. A duration for a particular work breakdown element can be derived 
from identifying which work package must start first (earliest) and which package will be the latest 


PART 3 DEFINING AND MANAGING PROJECTS 


to finish; the difference from start to finish becomes the duration for the sub-deliverable. The higher 
elements are used to identify deliverables at different stages in the project and to develop status 
reports during the Executing stage of the project life cycle. Thus, the work package is the basic unit 
used for planning, scheduling and controlling the project. To review each work package in the WBS 
consider the fellowing details: 


Defines the work to be done (what). 
Identifies the time to complete a work package (how long). 


Identifies a (time-phased) budget to complete a work package (cost). 


Pe 30h UN a 


Identifies resources needed to complete a work package (how much; people, plant and 
equipment; raw materials). 


5. Identifies a single person responsible for delivering and monitoring the work package (who). 
6. Identifies monitoring points for measuring progress (control). 
Includes specifications so quality can be checked (how well). 
8. Includes all required artefacts to execute the package (required information). 

A house build is used as an example of a WBS in Figure 7.12, and Table 7.5 illustrates an example 
of the contents of the work package, or ‘pack’. 


The level of detail in a work packages varies. However, in complex projects the pack of 
information, which makes up the work package, can be quite extensive. Inclusions typically found in 


re: House build example 
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Table 7.5 Example of a work package or pack contents 


Task description Felling and removal of all trees, as identified on the site plan by the chartered surveyor. All 
tree material, including the removal of stumps, is be carried out by the required date. 


Trees for removal have been marked with a fluorescentorange band tied around the base 


of the tree. 
Associated Mark site, Chartered Surveyor 
Milestone Foundations, complete 
Assigned to CutAbove Tree Services 
Contact: Ash, 0999 912 000 
Start/End Start 10 April 
End 14 April 
Resources CutAbove Tree Services to supply all required equipment. 
Project to provide safety supervisor onsite. 
Budget As quoted, $10 800 (incl. GST) 
Contract Contract to CutAbove Tree Services attached. 
Quality Adherence to AS/NZS 4801 
Technical Refer attached site plan. 
Attachments Copy of contract 
Site plan 
Other Safety induction to be carried out prior to entry on site. 


Source: @ 2018 Dr Neil Pearson 


the pack include technical specifications, plans/drawings/diagrams, quality assurance information, 
quality control information and contracts. The use of packs and work packages is prevalent in some 
industries, especially in construction (private and public) and in the IT industry. Although there is 
a cost to producing the packs (time in the project), the benefits to the project and the person/group 
allocated the task is seen to far outweigh this. Work packages, although often identified during scope 
development, are developed to this level of detail during the Planning stage of the project. 

Some organisations retain WBS item information within a central database, often referred to as the 
WBS dictionary. The information retained in the WBS dictionary would be similar to the information 
in the work package pack. As a minimum, the WBS item number, name, description and estimate 
information would be retained within the database. By retaining a database of WBS items, projects 
can re-use WBS items to build a new WBS, or to amend an existing WBS. The WBS dictionary can also 
provide a good source of estimating information and, when mined historically, inform current. 
estimating activities. Large government and military projects often leverage WBS dictionaries—in the 
author's viewpoint these are a valuable accompaniment to the WBS itself. 





Creating a WBS from scratch can be a daunting task. Project managers can take advantage of 
relevant examples from previous projects to begin the process and leverage WBS dictionaries if 
they exist. However, WBSs are the product of group effort. If the project is small, the entire project 
team may be involved in breaking the project down into its components (e.g. in a brainstorming 
workshop). For large, complex projects, the people responsible for the major deliverables are likely 
to meet to establish the first two or three levels of deliverables. In turn, further detail would be 
delegated to people responsible for specific work. Collectively, this information would be gathered 
and integrated into a formal WBS by a project officer. The final version would be reviewed by the 
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Figure 713 WBS terminology 
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inner echelon of the project team for accuracy, completeness, and detail. Relevant stakeholders 
(most notably customers and sponsors) would be consulted to confirm agreement and to carry out 
revisions when appropriate. 

Project teams developing their first WBS frequently forget that the structure should be end-item, 
output-oriented. First attempts often result in a WBS that follows the organisational structure—design, 
marketing, production, finance. If a WBS follows the organisational structure, the focus will be on the 
organisation’s function and processes rather than on the project's output or deliverables. In addition, a 
WBS with a process focus will become an accounting tool that records costs by function rather than a 
tool for output management. Every effort should be made to develop a WBS that is outputoriented in 
order to concentrate on concrete deliverables. 

Alternative terminologies are also used around the differing levels of a WBS. Figure 7.13 indicates 
other terminology that is often encountered to describe the design of a WBS. The PMI uses the levels 
terminology and has a dedicated publication on the subject of WBSs, referred to as the Practice 
Standard for Work Breakdown Structures (PMI 2006). 


7.4.3 Practice techniques used to develop the WBS 


Development of the WBS can be undertaken as a team activity and a method commonly used for this 
involves Post-it® notes. First, empty a room, leaving only a table that has Post-it notes on it. Next, 
invite various groups or individuals to come into the room to brainstorm development of the WBS. 
Differently coloured Post-it notes can be used to represent different levels of the WBS, or the different 
groups responsible for doing the work, or to indicate which groups/individual added the items to 
the WBS. Once the WBS has been captured to the required level of detail, it should be moved into a 
software package (e.g. Microsoft® Visio, OmniGraffle® (on the Mac)), or into specialist tools such 
as Matchware® (www.matchware.con/er/products/mindview/default.htm) so it can be circulated to a 
wider group for input and review, modified and adjusted. 

Another technique that can be used is ‘mind-mapping’. Mindmaps almost duplicate the structure 
of a WBS, but in a more freeflowing format. To create a mind-map, first start with the project’s 
name as the centre ‘node’ and then build out curved lines (deliverables) one at a time; each new 
line added is akin to a new level being added on the more formal WBS structure. Whiteboards, or 
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mindmapping tools (orchestrated by a facilitator), provide ideal platforms for constructing mind 
maps. The author has used a number of tools to mindmap projects, such as www.thinkbuzan.com 
and www.thebrain.com. 

Astructured English list format is also commonly used, which involves an indented list of numbered 
points being developed. Engineers and logical thinkers tend to prefer this style as it provides them with 
a format that is familiar to them in their daily roles. There is no single correct way for constructing 
a solid, comprehensive and well-devised WBS. The key is to understand the preferred working style 
of the people who are to be involved in development and also the end goal to be achieved. Ideally, 
the project manager should not be the facilitator of the brainstorming session if they are also to be 
involved in the development of the WBS. In this scenario, consideration should be given to using an 
independent facilitator instead. Note: By using Post-it notes, whiteboards or software tools, there is 
always an opportunity to make changes on-thefly. Refer to Figure 7.14 for a simple example of each 
approach. 


7.5 STEP 4: INTEGRATING THE WBS WITH THE 
ORGANISATION 


The WBS can be used to ‘link’ the organisational units responsible for performing the work. In practice, 
the outcome of this process is the organisation breakdown structure (OBS). The OBS depicts how 
the firm is organised to discharge work responsibility (i.e. outwork of work packages to departments). 
The purpose of the OBS is to provide a framework to summarise organisational unit work performance, 
identify organisational units responsible for work packages and tie the organisational unit to cost 
control accounts. The OBS defines the organisational subdeliverables in a hierarchical pattern, in 
successively smaller and smaller units. Frequently, the traditional organisational structure can be 
used. Even if the project is completely performed by a team, it is necessary to break down the team 
structure for assigning responsibility for budgets, time, and technical performance. 
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Figure 745A Integrations of the WBS and @BS 
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As in the WBS, the OBS assigns the lowest organisational unit the responsibility for work packages 
within a cost account and herein lies a major strength of using the WBS and OBS together as they 
can be integrated (as shown in Figures 7.15A and 7.15B). The intersection of work packages and 
the organisational unit creates a project control point that integrates work and responsibility. The 
intersection of the WBS and OBS represents the set of work packages that are necessary to complete 
the sub-deliverable located immediately above and the organisational unit on the left, responsible for 
accomplishing the packages at the intersection. 


7.6 STEP 5: ESTIMATING—MOVING TOWARDS A 
DRAFT BUDGET AND SCHEDULE 


Once the WBS has been captured, refined, and (for the most part) socialised within the project team 
(albeit potentially a relatively small team during most project initiation stages), the WBS will need to 
be translated into a format that facilitates general access and ease of maintenance. The detail of the 
WBS during the project Initiating stage will not be as extensive as the WBS developed throughout the 
Planning stage of the project. Regardless of the detail captured during the scoping of the project, the 
WBS provides an ideal structure for estimating (estimating is the focus of Chapter 8). 

Estimating at the Planning stage of the project life cycle is geared towards defining the overall 
timeframe and budget for the project, to a tolerance that is typically +/— 5-10%. (The importance of 
including both items in the scope document was outlined in the authors’ top 2@ scope inclusions as set 
out earlier.) The typical journey at this point of proceedings is captured in Figure 7.16. An estimate 
of the resources, durations and costs should be made against each subtask (or work package). From 
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Figure 7.15B Integrating the WBS and OBS—house build example 
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this estimating information, it is then possible to take the task and duration information and derive a 
timeline and total estimated project start and end date. With resource, duration and cost information, a 
derived estimate for the overall project budget can also be estimated. (Capturing the estimates against 
each WBS element is discussed extensively in Chapter 8.) 

The WBS is typically maintained throughout the life of the project. However, the content of the 
WBS will move into other tools the project manager can leverage to further plan, monitor and control 
against. 
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Figure 7.16 The journey from WBS to estimating and the creation of the project budget, schedule and resource 
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As illustrated in Figure 7.16, the time and duration information for each WBS element is typically 
captured in a project scheduling software package (Microsoft Project™ is a popular choice for 
this task). However, financial information may be maintained within a spreadsheet or within the 
organisation’s Enterprise Resource Planning (ERP) system. In its visual form, the WBS makes a useful 
addition to the scope document, since it provides readers of the scope document with a whole-of- 
project perspective and a breakdown of the elements of the project. 

Note: The PMI introduced the ‘100 per cent rule’ implying that if an activity (and associated tasks 
and subtasks) is not captured within the WBS, then it is not part of the project. With changes in thinking 
(such as a more incremental approach to project management), this is now open to some debate. This 
does not stop the project manager including ‘planning packages’ in the WBS that indicate that further 
detailed planning is required when the project approaches the package, i.e. the concept of rolling wave 
planning. A modified Smart Watch WBS indicating planning packages is illustrated in Figure 7.17. 

With the scope document content now formed, the project manager has to consider the second of 
the two key artefacts developed during the Initiating stage: the Scope Management Plan. 
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Figure 717 Modified WBS showing planning packag¢ 
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7.7 THE SCOPE MANAGEMENT PLAN 


The Scope Management Plan provides information and governance on how scope control and change 
control are to be handled across the project life cycle. The typical contents of a Scope Management. 
Plan include: 


E The process to be applied for all project change requests: This is the key process that outlines the 
steps to be taken on any change request being raised. 


E The process for scope verification: This outlines the steps and governance around due diligence 
and verification of the scope document prior to its final approval. 


E The process for deliverable acceptance: Deliverables (outcomes or outputs) will be delivered 
throughout the life cycle of the project. The process for documenting and signing off deliverables 
is defined early on in the project, so that everyone in the project team is aware of the process. 


E How lessons-learned will be captured and applied within the preject: Lessonslearned should not be 
a oneoff event during the closure of a project as they provide a continuous improvement opportunity 
throughout the life of the project. Project team meetings provide an ideal setting for capturing and 
reflecting on ‘what went right’, ‘what went wrong’ and ‘what could have been done better’. 


Source: @ 2013 Br Neil Pearson 


The Scope Management Plan would be approved along with the scope document. and would also 
be communicated to all those in the project team, to ensure that processes and governance are being 
applied consistently across the life of the project. 

Note that in practice, it is useful to separate projectrelated documents into three categories: 


1. Management Plans (such as the one discussed for scope), where the more static governance, 
processes, roles and responsibilities are defined. Often these remain in effect throughout the 
life cycle of the project. PMBOK uses the term ‘Organisational Process Assets’ that are typically 
captured in these management plans. 
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2. Dynamic, living, project management artefacts: These are all-important for the project manager 
and capture, describe, monitor and track the various dimensions of the project (e.g. the Risk 
Register or Stakeholder Matrix). 

3. Product artefacts: These are related to the product/service being produced; they can be vast and 
varied in nature (from product specifications to software code). 


2 


7.8 CHANGE REQUEST MANAGEMENT 


A major aspect of any project is change request management. As outlined above, this process is 
typically documented within the Scope Management. Plan. Not every detail of a project plan will 
materialise as expected, resulting in changes to the project scope. (Note: Some organisations use the 
word ‘variations’ instead of ‘change’; therefore be sure to clarify your terminology with the business 
from the outset.) Coping with and controlling project changes requests can a formidable challenge 
for most project managers. Changes come from many sources such as the project customer, project 
owner, project manager, team members, and from risks that eventuate into issues. Most changes easily 
fall into the following three categories: 


1. Scope changes for design changes or additions: These can represent significant variations if, for 
example, the customer requests a new feature or a redesign that will improve the product. 


2. Implementation of contingency plans: When risk events do occur (and become Issues), these can 
result in changes to baseline costs and schedules. 


3. Improvement changes suggested by project team members. 

Because change is inevitable, the establishment of a well-defined process that captures changes, 
reviews (analyses changes), and implements changes is essential. Project change control processes 
involve recording, analysing and controlling changes to the project baselines (scope baseline, costs 
baseline and schedule baseline). Some organisations consider change control systems as part of 
configuration management, while others may have a documented change control process that is 
enforced through the project management office. Regardless of the source of the change control 
process, in practice, most change control processes are designed to accomplish the following: 

1. Identify proposed changes. 
2. Record proposed changes. 


3. Analyse the impacts of change across the areas of scope, time, cost, quality, resources, 
communications (and information), risk, procurement and stakeholders. 


4. Review, evaluate, and approve or disapprove changes formally. 
5. Negotiate and resolve conflicts of the change (conditions and cost). 
6. 


Communicate changes to all parties affected (requestor, customer, sponsor and project team). 


N 


Assign responsibility for implementing the change. 


go 


Update documents, including the master schedule and budget (rebaseline these if necessary). 
Remember that a project has three baselines: the scope baseline, the schedule baseline, and the 
cost baseline. One or all could be affected by the change. 

9. Track all changes to be implemented in relation to where the change is within the process, and 
who (within the project team) is working on the change. 


Figure 7.18 illustrates a swimlane process diagram that captures these steps. Note: Swimlane 
diagrams such as this are becoming the common way to articulate project management processes in 


Figure 7.18 Change control Swimlane proc 
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organisations. The Swimlane can represent a role (e.g. the project manager), a group (e.g. the Change 
Control Board), or an IT system (not used in this Swimlane diagram). Common notations used are 
based on UML (Unified Modelling Language) or BPMN (Business Process Model and Notation), as 
used in this figure. 

On small projects, the change control process may simply entail approval being sought and given 
by a small group of stakeholders. On larger projects, more elaborate decisionmaking processes will be 
utilised, with different governance levels (approvals) having to be gained for different impact levels of 
change. For example, changes in performance requirements may require multiple signoffs (including 
signoffs by the project sponsor and client), whereas the project manager can usually independently 
authorise something such as switching suppliers or a cost overrun of a fixed amount $5000 (subject to 
contingency arrangements). Regardless of the nature of the project, the goal is to establish the process 
for introducing necessary changes in the project in a timely and effective manner. 

Assessing the impact of change on the project is particularly important. Often solutions to 
immediate problems have adverse consequences on other aspects of a project. For example, if, in 
overcoming a problem with the exhaust system for a hybrid car, the design engineers add a new element 
that contributes to the overall prototype’s weight, this may cause allowable weight parameters to be 
exceeded. It is important that people with appropriate expertise assess the implications of changes. On 
construction projects, this is often the responsibility of the architecture firm, while software architects 
perform a similar function with software development endeavours. 

Organisations use Change Request Forms and registers to track proposed changes. An example 
of a simplified Change Request Form is depicted in Figure 7.19. Typically, Change Request Forms 
include a description of the change, the impact of not approving the change, and (dated) requestor 
and project signatures. Keep in mind that change requests acknowledge and receipt the request for 
change, but do not mean that the change being requested has been accepted at this stage in the change 
control process. A lesson-learned from years of practice in recording change is to always ensure that 
the requestor of the change fully completes the initial description of the change. As a project manager 
or project team member, it is very easy to incorrectly interpret a request for change after a busy 
meeting, or after a discussion at a coffee machine, or when information is passed to you second hand. 

An abridged version of a Change Request Register for the Smart Watch project is presented in 
Figure 7.20. These types of registers are used to monitor change requests. They typically summarise 
the status of all outstanding change requests and include useful information such as the source of and 
date of the change, project team member assigned, cost estimates and the current status of the change 
request. 

If the change control system is not integrated within the project environment, then the project 
plans and overall control will soon self-destruct. Thus, the key to a successful change control process 
is to carefully document all changes and educate the project team to follow this process at all costs, 
for any and all changes, regardless how insignificant they may first appear! 

The benefits derived from change control systems include the following. 


Inconsequential changes are discouraged by the formality of a process. 
Costs of changes are maintained in the Change Request Register. 
Integrity of the scope, WBS and performance measures is maintained. 
Allocation and use of budget and management reserve funds are tracked. 
Responsibility for implementation is clarified. 

Effect of changes is visible to all parties involved. 


Implementation of change is monitored. 


Scope changes will be quickly reflected (if approved) in baseline and performance measures, 
from which project execution is taking place. 
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Figure 7.19 S 
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Clearly, change control is important and requires that an individual or a particular group be 
responsible for approving changes, keeping the process updated and communicating changes to 
the project team and to relevant stakeholders. Project control depends heavily on keeping the change 
control process current. As a bonus, the historical record of changes can be used to satisfy customer 
enquiries, identify problems in post-project audits, and to feed information into the LessonsLearned 
Register, for the benefit of future projects. 
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Figure 7.20 Change Request Register 
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7.9 SCRUM/AGILE CONSIDERATIONS 


Scope in Scrum is very much determined by the product owner and what stories are to be considered 
for the entire project in the form of epics, increments and sprints (see Chapter 3). Remember that 
the degree of change (or degree of ‘unknowns’) in the project’s requirements will influence the 
approach taken (see Chapter 2) and will affect how requirements are managed into and out of scope. 
If requirementsare subject to change and/or are relatively unknown, then a Scrum approach would be 
selected over a more Predictive (traditional) approach. 


Summar 


Clearly defining your project is the first and most important step in the project management life cycle. Following 
approval of the scope document, the project proceeds into the Planning stage of the project life cycle. 


This chapter has highlighted: 


m That the absence of a clearly defined project scope document consistently shows up as a major reason for project 
failures. Closely coupled with this is the absence of a change control process, meaning that after the scope has been 
documented and agreed, there is little contro! over scope creep. Projects therefore often go beyond the original 
scope of the project, incur extra costs, and overrun scheduled completion dates. 

m The project scope definition and WBS are the keys to nearly every aspect of planning and (subsequent) execution of 
the project. The scope definition provides a focus and emphasis on the end result of the project. Establishing project 
priorities allows managers to make appropriate trade-off decisions. 

m The project's scope document is the single source of scope for the project and must be defined with a high degree 
of accuracy, completeness, buy-in, agreement and with a holistic (overarching) consideration of the project and 
business environment. 

m Articulation of governance and processes for the management of scope (including change control) is captured in the 
Scope Management Plan. This must be communicated and reinforced to the project team. 

m The importance of having an established requirements management process and associated tools (documented in 
the Requirements Management Plan). The criticality of ensuring that requirements are well formed, applying all the 
requirements filters. 
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BPMN project charter rich picture 
context diagram requirements analysis scope creep 
deliverable requirements elicitation scope document 
dis-benefits requirements filters Scope Management Plan 
exclusions (out-of-scope) requirements management scope, statement of work (SoW), 
hierarchical decomposition requirements planning scope statement 
inclusions (in-scope) Requirements Traceability Matrix seven constraints 
milestone requirements traceability, swimlane diagram 
organisation breakdown backwards triple constraints 
structure (OBS) requirements traceability, forwards work breakdown structure (WBS) 
outcomes requirements validation WBS dictionary 
outputs requirements verification work package 


Review questions 


1. What are the main elements of a typical scope document? 

2. What questions does a project objective answer? What would be an example of a good project objective? 
3. What does it mean if the priorities of a project include ‘time constrain’, ‘scope accept’ and ‘cost enhance’? 
4. What kind of information can be included in a work package? 

5. What is the ‘100 per cent rule’ and how does the iterative or staged approach to projects affect it? 

6. What are the main stages in a project change control process? 

7. How can a Scope Management Plan assist in communicating process and governance? 

8. What are the stages in the requirements management process? 





9. What are the key categories of requirements types? 
10. How are requirements captured in the Scrum (Agile) approach? 


1. Complete a simple Requirements Traceability Matrix for a project you are currently working with, using Figure 7.8 as 
a guide. 


N 


You are in charge of organising a dinner-dance concert for a local charity. You have reserved a hall that will seat 30 

couples and have hired a jazz band. 

(a) Develop a scope statement for this project that contains examples of all 20 elements of a scope document. 
Assume that the event will occur in four weeks’ time and provide your best ‘quesstimate’ of a date for each of the 
milestones. 


(b) What would the likely priorities be for this project? 
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In small groups, identify real-life examples of a project that would fit each of the following priority scenarios: 
(a) Time-constrain, scope-enhance, cost-accept 

(b) Time-accept, scope-constrain, costaccept 

(c) Time-constrain, scope-accept, costenhance. 


Develop a WBS for a project in which you are going to build a bicycle. Try to identify all of the major components of the 
project and provide three to four levels of detail within the WBS. 


Develop a WBS for an organisation with 12 employees about to undergo an office move toa greenfield site. Be sure 
to identify the deliverables and the organisational units (people) responsible for the work packages. Code your WBS. 
Develop a corresponding OBS that identifies ‘who is responsible for what’. 


Your roommate is about to submit a scope statement for a spring concert sponsored by the entertainment council at 
the University of Queensland (UQ). UQ has over 32 000 undergraduate students and 11 000 postgraduate students. 
This will be the first time in a number of years that UQ has sponsored a spring concert. The entertainment council has 
budgeted $40 000 for the project. The event is to occur on 5 September. Since your roommate knows you are taking a 
class on project management, they have asked you to review their scope statement and make suggestions for potential 
improvements. They consider the concert to be a resume-building opportunity for them and therefore want to be as 
professional as possible. Below is the draft of the scope statement they have prepared to-date. What suggestions 
would you make about the drafts contents, and why? 





UQ SPRING MUSIC CONCERT 


Project objective 
To organise and deliver a six-hour music concert 


Deliverables 


m Concert security 

m Contact local newspapers and radio stations 
m Separate beer garden 

m Six hours of musical entertainment 

m Design a commemorative concert t-shirt 
m Local sponsors 

m Food venues 

m Event insurance 

m Safe environment 

Milestones 

4. Secure all permissions and approvals 

2. Signa big-name artist 

3. Contact secondary artists 

4. Secure vendor contracts 

5. Advertising campaign 

6. Plan set-up 

7. Concert 

8. Clean-up 


Technical requirements 


ds 


Ci pa BS) 


Professional sound stage and system 

At least five performing acts 

Restroom facilities 

Parking 

Compliance with UQ and Brisbane City/local council requirements/ordinances 
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Constraints 
m Seating capacity for 8000 students 
m Concert must be over at 12:15am 


Assumptions 

m Performers are responsible for travel arrangements to and from UQ. 

Performers must provide own liability insurance. 

Performers and security personnel will be provided with lunch and dinner on the day of the concert. 
Vendors contribute 25 per cent of sales to concert fund. 


Neng 


Create a Requirements Traceability Matrix by extracting requirements from the case study and adding in others you 
assume would form part of the required solution—remember you could validate these missing requirements with 
relevant stakeholders as part of the review process. 

8. Below are four mini-case studies from practice. Break into small groups and (a) analyse the case and (b) provide five 
recommendations to the project sponsor as to: What do you do? What impact do your decisions have on the project’s 
cost, schedule and performance? 


Project A 
You've just taken over a project from another project manager and have come back from a very uncomfortable meeting 
with your business sponsor. In the meeting, the sponsor told you how dissatisfied he is with the project’s performance 
to date and that he’s getting ready to pull the plug on the project entirely. Deadlines keep slipping, the application isn’t 
complete, and the sponsor feels like he can’t get in touch with anyone to give him an update on the project’s status and 
progress. 
From conversations with your project team, you learn that requirements still haven't been finalised and the team is 
waiting for input before being able to proceed on several key parts of the application. Despite that, they've been able to 
push forward in other areas, and are quite proud of the work they've done. However, they haven't had a chance to show 
it to the sponsor. 
To complicate matters further, your boss has made it clear that this project must be completed on schedule because he 
needs the resources for another project. 

What do you do? What impact do your decisions have on the project's cost, schedule and performance? 





Project B 
Your project team has finished gathering the requirements and developing the solution design. Your team is broken into two 
main groups. The first group consists of the project manager, business analysts and management, and is located in Australia. 
The second group consists of the development and QA (quality assurance) teams, and is located in India. 

The work breakdown structure (WBS) was developed based on estimates from the teams in India. The development team 
agreed to provide daily updates to you about progress against the WBS to make sure the project's milestones are going 
to be met. However, by the time the development team got close to the first milestone, it became obvious that it was 
falling behind even though its daily updates indicated that it was on track. In addition, the team adopted a different design 
approach than the one agreed upon at the beginning of the project. 
The lack of meaningful updates from the development team, along with a different design track has jeopardised the 
entire project, by rendering the whole plan obsolete. Your team is now at risk of not delivering the project. 

What do you do? What is the impact to cost, schedule and performance? 





Project C 
You have just taken over as the program manager of a large program with multiple tracks and a go-live scheduled 
in three months. At the first meeting with the project sponsors and key stakeholders, you find out that the business 
requirements are not complete and in some cases not started. Furthermore, the project scope is not realistic to be 
able to meet the upcoming ‘go-live’ and overall, the project teams are confused due to a lack of communication and 
understanding of priorities. 

What do you do? What impact do your decisions have on the project's cost, schedule and performance? 





Project D 
You've just been assigned to take over a new project from an outgoing project manager. It is a high-visibility project 
that is using a development methodology that is new to you and to your company. In your transition meetings with the 
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outgoing project manager, she assures you that development is complete and that all you have to do is ‘shepherd’ the 
project through acceptance testing and release. As a result, you released several project team members, as scheduled. 
The acceptance testing does not go as smoothly as planned. The application has more defects than anticipated, 

and some core functionality cannot be tested. The project team doesn't feel like it is getting the direction it needs to 
continue moving forward, and furthermore, the business sponsor has asked you when she can expect to test application 
functionality that you didn’t know was in the scope. Your project’s deadline is rapidly approaching and inter-project 
dependencies make it unlikely that you will be able to push your launch date. 

What do you do? What impact do your decisions have on cost, schedule and performance? 
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CHAPTER 8 


ESTIMATING TIME, COSTS 
AND RESOURCES 


Learning elements 




















SA Understand the differing levels of estimating accuracy that are most relevant to the 
project life cycle stage. 

8B Understand factors that influence estimating in practice. 

8C Comprehend and apply different approaches to estimating, including top-down, 
bottom-up and hybrid. 

8D Comprehend and apply numerous estimating techniques to the areas of time, costs 
and resources. 
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8.1 Introduction 

8.2 Factors influencing the quality of estimates 

8.3 What is being estimated? 

8.4 Estimating guidelines for resources, time and costs 

8.5 Top-down versus bottom-up estimating 

8.6 Methods for estimating project resources, time (durations) and costs 
8.7 Additional estimating considerations 


Summary 
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8.1 INTRODUCTION 


Understanding estimating is key to ensuring that accurate (to the stage of the life cycle) commitments 
are identified, estimated, and accounted for in the relevant project document. 

As can be seen in Table 8.1, the techniques and tools of estimating are common across the 
estimation of time (durations), costs and resources (human and other). So, rather than discussing the 
topic of estimating three times in each respective chapter, we have instead pooled it here into an easily 
accessible single resource and we hope our readers find this a more useful approach. 


Table 81 Estimating time (duration), cost and resources—and links to other chapters 


Knowledge area 


Project schedule 
management 


Project cost 
management 


Project resource 
management 





What’s included PMBOK, PMI 2017, | PMI tools and techniques applied Relates to chapter in 
reference this text 


This includes the processes PMBOK p 173 Expert judgement Chapter 9: Project 

to estimate time units for any Analogous estimating schedule management 
identified resources required by Parametric estimating 

the project. Three-point estimating 


Bottom-up estimating 
Data analysis 
Decision-making 


Meetings 
This includes the processes to PMBOK p 231 Expert judgement Chapter 10: Project 
estimate costs for, and associated Analogous estimating cost management 
with, any identified resources Parametric estimating 
required by the project. Bottom-up estimating 


Three-point estimating 

Data analysis 

Alternatives analysis 

Reserve analysis 

Cost of quality 

Project Management Information system 
Decision-making (voting) 


This includes the processes to PMBOK p 307 Expert judgement Chapter 13: Project 
estimate all the actual resources Bottom-up estimating resource management 
required by the project, including Analogous estimating 

details of quantities, how they are Parametric estimating 

to be sourced and any associated Data analysis 

resources required to enable Project Management Information System 

these key resources. Meetings 


Where there is an urgent need to start work on a project quickly, a project manager may minimise 
or avoid the effort needed to follow through on estimating project time, costs and resources. This is a 
huge (and often costly) mistake to make. There are important reasons why it. is necessary to invest the 
effort and time needed to complete estimating in the project (appropriate to the stage of the life cycle 
it is in) and manage the expectations of your organisation. 


Estimates of time, cost and resource are needed to: 


support fact-based decisions with key project stakeholders 
determine whether the project is worth doing 

determine how long the project should take, and its overall cost 
schedule the work (tasks and work packages) of the project 
determine resources required (human and other) 

develop time-phased budgets 


assist in establishing the scope baseline, the cost baseline and the schedule baseline 


enable a determination of how well the project is progressing (from the baselines) in 
subsequent project stages. 
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Estimating is the process of approximating the resources required and the time and cost of 
completing the project's deliverables. Estimating processes are frequently classified as top-down and 
bottom-up. The time available and project stage will often influence whether top-down (high-level) 
or bottom-up (detailed) estimates are utilised. Top-down estimates are usually applied by project 
managers when time is short, or when in the Initiating stage of the project. Project managers will often 
derive estimates from analogy, group consensus or mathematical relationships. The project team 
members, however, typically perform bottom-up estimates (when time has been allowed for the extra 
detail to be appropriately researched). Their estimates are based on estimates of each element found 
in the work breakdown structure (WBS), usually at the lowest level (task and work package). Bottom 
up estimating is normally carried out in the Planning stage of the project to ensure that estimates of 
the project are as accurate as possible. 

All project stakeholders desire accurate time, cost and resource estimates, but they generally also 
understand the inherent uncertainty in all projects and the effort that estimating often consumes. 
Inaccurate estimates, however, lead to false expectations and customer dissatisfaction. Accuracy may 
be improved with greater effort, but of course estimating costs money! It is usually worth the time 
and effort involved, because of the obvious benefits that can be gained (realistic expectations and 
customer satisfaction being but two). In essence, project estimating becomes a trade-off—balancing 
the benefits of achieving better accuracy against the costs involved in securing increased accuracy. 

Time, cost and resource estimates arguably represent a lifeline in project control. This is because: 


Em They serve as a baseline for comparing actual costs, times (durations) and resources (utilised) 
throughout the life cycle of the project. 


Project status reports depend on reliable estimates as their major input for measuring variances 
so that corrective action(s) can be taken as needed. 


mu Estimates become the planned baseline value at the start of the project’s Executing stage. 


Ideally, the project manager, and in most cases the customer, would prefer to have a database 
of detailed time (duration), cost and resource estimates for every work package in the project— 
regrettably, such detailed estimating is not always possible or practical. 


Project estimating is a complex process: estimates of time, costs and resources together allow the 
project manager to develop a timephased budget, which is imperative for project control. 


Before we delve fully into estimating, let’s start out by exploring some of the more holistic factors 
that influence estimating. 


8.2 FACTORS INFLUENCING THE QUALITY 
OF ESTIMATES 


A typical statement in the field of project management revolves around the desire to ‘have a 95 per 
cent probability of meeting time and cost estimates’. Past experience is a good starting point. from 
which to develop time, cost and resource estimates. However, estimates based on past experience 
almost always need to be refined by other considerations in order to reach the ‘95 per cent probability’ 
level. Factors related to the uniqueness of the project will have a strong influence on the accuracy of 
estimates. ‘Project’, ‘people’ and ‘external’ factors will all need to be carefully considered in order to 
improve the quality of estimates. 


8.2.1 Planning horizon 


The quality of the estimate will depend on the planning horizon—estimates of current events will be closer 
to 100 per cent accurate, but this accuracy will be reduced the more distant (further into the future) the 
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Figure The estimating trumpet 


Most probable final co t 







Ideal target cost 


10-a" (-----------4--------4-------- _| -----f--==SSRE==== 


Aporox. % estimate value range (ratio scale) 





5 10 15 25 50 80 85 








Economic studies] Feasibility studies 





Committed 


Source: © R. Max Wideman http://www.maxwideman.com 2002 reproduced with permission. This material is offered to individual 
readers who may use it freely in connection with their preject work, It may not be used by commercial or non-commercial 
organizations without permission 


events are. The accuracy of time, cost and resource estimates should improve as we move from the Initiating 
stage to the point where individual work packages are defined within the Planning stage. 

The estimating accuracy trumpet produced by R. Max Wideman (refer to Figure 8.1) provides an 
industry standard for expectations that prevail in the industry and can therefore be used when setting 
expectations with executive management, sponsors, steering committees and customers. This, after 
all, is the principle of rolling-wave planning. 

Rolling wave planning is the technique of only planning in detail the work that is to be undertaken in 
the near term. As the project manager moves forward in the project, work that was possibly indicated 
as a ‘planning package’ on the WBS will be expanded, and planned in detail when the time has arrived 
to do so. There may be many reasons why a work package has not been developed into a detailed plan 
but left for expansion in the future; for example, the currently unknown outcomes of preceding work 
packages may need to be known to carry out the planning, or itis not a good use of resources to plan 
a future work package in detail now, when nearer term work packages require attention. This is a 
common occurrence in Iterative project approaches. 


8.2.2 Project duration 


Long projects typically experience the most problems, when estimates have been prepared months 
(and sometimes years) in advance. If estimates do not include a stated factor for potential increases in 
(either costs, durations or resources), this can accordingly affect accuracy. For example: 


@ Some projects have failed to consider that changes to workplace health and safety legislation 
may occur—this has consequently extended the durations of some activities and has led to new 
activities being introduced into the overall project. 
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Em The time required to implement a new technology project often has a propensity to expand in an 
increasing, non-linear fashion, as unrealistic estimates of work were committed to. 


E Sometimes, poorly written scope specifications for new technology required in a project also 
result in errors in estimating durations as the technology is essentially, ‘cutting-edge’ or ‘green 
field’ and patterns for estimating are often not available or reported on in industry. 


Given that (generally) the level of uncertainty around estimating increases in long-duration 
projects, careful consideration needs to paid to how these type of projects should be approached. 
Generally, the simple three-month rule is applied to estimates—any estimate older than three months 
needs to be re-estimated or re-confirmed with the supplier. 


8.2.3 People 


A people factor can also be responsible for errors being introduced into time, cost and resource 
estimates. For example, the accuracy of estimates will depend on the skills of the people making them. 
A close match of ‘people skills’ to the work package being estimated will undoubtedly beneficially 
influence both productivity and learning time taken. Similarly, whether members of the project team 
have worked together before on similar projects is likely to influence the time it. takes to coalesce 
members into an effective team. Sometimes, factors such as staff turnover can impact the process of 
estimates. It should be noted that adding new people to a project increases time spent communicating. 
Typically, people have only five to six productive hours available for each working day; the other 
hours are taken up with indirect work such as meetings, paperwork, answering email and building 
professional working relationships. 


8.2.4 Project structure and organisation 


The project structure chosen to manage the project will influence time, cost, and resource estimates. 
One of the major advantages of having a dedicated project team in place (as discussed in Chapter 5) is 
the speed gained from their concentrated focus and ability to make localised project decisions. Speed 
comes with the additional cost of tying up personnel full time, however. Conversely, when projects are 
operated in a matrix environment, this may serve to reduce costs as personnel can be more efficiently 
shared across projects—a drawback being that it may take longer to complete the project, given that 
the attention of personnel is divided up and that coordination demands are higher. Where a project 
team member's working time is split 5@/5@ (per cent) between the project and business as usual (BaU), 
it may be that only 40/40 (per cent) work output is achieved from them (through no fault of their own), 
as 20 per cent will likely be lost in task switching. 


8.2.5 Padding estimates 


In some cases, some people are inclined to pad estimates. For example, if a person is asked how long 
it takes them to drive to the airport from their (base) place of work, they might state an average time 
of 30 minutes, assuming they have a5@ per cent chance of getting there in 3@ minutes. If asked what the 
fastest timeframe would be that they could possibly get there, they might then reduce their estimation 
of the required driving time down to 20 minutes. Finally, when asked how long the drive would take 
them if they absolutely had to be there to meet with your customer, it is likely that they would increase 
their estimate to say, around 5® minutes, to ensure they would not be late. This similarly occurs in work 
situations when the project manager is asked for time, cost and resource estimates—project managers 
may be inclined to add a little padding to increase the probability of accuracy and to reduce the 
probability (risk) of inaccuracy (i.e. being late). If everyone at all levels of the project were to adda 
little padding to reduce such risk, the project's duration (time), cost and resource (commitment) would 
be seriously overstated. This phenomenon often causes some managers or customers to call for a 
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10-15 per cent cut in time and/or cost estimates for the project, but of course, the next time this game 
is played, the person estimating cost and/or time is highly likely to hike (pad) their estimate to 20 per 
cent or more. Clearly, such ‘games’ defeat the chance of being able to achieve realistic estimates and 
yet realistic estimates are what are needed in order to be competitive. 

As a professional of the discipline, it is the project manager's responsibility to ensure that. clear 
governance is established around the use of padding. Some project managers establish a clear policy 
of ‘no padding’, stating that an appropriate contingency will be added to the project. Contingency 
is typically held by the sponsor or the project management office (PMO) and to gain access to funds 
sitting in the contingency account, the project manager has to make use of the change request process 
(outlined in Chapter 7). (Note also that a detailed discussion on task, work package, control account 
and project contingency takes place in Chapter 10.) 


8.2.6 Organisational culture 


Organisational culture can significantly influence project estimates. In some organisations, estimate 
padding is tolerated (and even privately encouraged in some cases). Other organisations place a 
premium on accuracy, and strongly discourage estimating ‘gamesmanship’. 

Organisations vary in terms of the importance they attach to estimates. The prevailing belief in 
some organisations is that detailed estimating takes too much time and is not worth the effort, or 
that it’s impossible to predict the future and therefore why bother estimating? Other organisations 
subscribe to the belief that accurate estimates are the bedrock of effective project management. As 
can be understood therefore, organisational culture shapes every dimension of project management 
and estimating is not immune to this influence. 


8.3 WHAT IS BEING ESTIMATED? 


Before looking at some of the tools and techniques used in estimating, we must first consider what is 
being estimated against each of the tasks that make up the work packages. When a project manager 
estimates a work package, they need to consider what resources are required, how long these 
resources are required for (the time/duration) and the cost of these resources, plus any additional 
items required to successfully complete the work package. 


8.3.1 Resources 


‘Resource’ is the generic term used in project management. for any item that is consumed by the 
project. The range of potential resources needed for a project can vary considerably and are of course 
impossible to accurately document in full. Having said this, Table 8.2 provides a snapshot of some of 
the more commonplace resource types frequently encountered in projects. 


Table 8.2 Typical types of resources utilised by projects 


Human resources internal employees (full or part time), contractors, ‘temps’, consultants, secondments, 
volunteers, freelancers. 

Tools Testing equipment, compressors, drills, desktop computers, telephones, tablet devices, 
access to information (libraries), internet, software licences. 

Plant Office facilities, warehouse (storage) space, production lines. 

Equipment Utes, cars, hoists, scissor lifts, trucks, desks, filing cabinets, printers, network equipment, 
servers, telephone systems (PABX). 

Raw materials Concrete, fill, steel, roofing tiles, fencing panels, circuit boards, plastic pellets (‘nurdles)). 

Capital Funding sources, cash flow into the project, loans, equity, venture capital. 

Services Consultancy, maintenance, facilities, data centre services, cleaning, catering, security. 


Other Paper, printers, books, insurance, training, consumables, subscriptions, energy consumption. 
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The range of resource types will be refined as the project manager builds out the work packages 
and starts to estimate the resources required to complete each work package. The project resource/ 
skills matrix is often used to capture details of the human resources required, allowing for further 
analysis of this dimension (see Chapter 13). The cost information will have implications for the project 
budget (see Chapter 1@ ), and time information for the project network/schedule (see Chapter 9 ). This 
illustrates the integrative nature of project management and the complexity involved in juggling the 
many dimensions of the project. 


8.3.2 Time (durations) 


Once resources have been identified against items within each work package, the duration that each 
of these will be required for needs to be captured (estimated). For some kinds of resources this is a 
relatively straightforward task; for example, if a specialist contractor is required for 1® work days of 
effort or a cement pump is required for two weeks on site. Other resource costs (such as those relating 
to human resource costs or costs associated with equipment that is needed in an ad hoc way over an 
extended period of time) will need somewhat more of a holistic consideration. 

A project manager has to ask themselves whether it is most cost efficient to deploy the resource 
to only the required tasks it has been identified against or whether it is more efficient to keep the 
resource for a longer duration, or even for an entire phase of the whole project. Take, for example, 
plant. and equipment costs: there will be costs associated with bringing the item on site, setup time, 
tear-down time and transport costs. Does having to carry out this sequence multiple times ona project 
exceed the cost of instead retaining the equipment on site for a longer duration of time? The same 
applies to human resources: if an electrical tester is required for several activities towards the end of 
the project, does the project manager pay a higher day rate and take the risk of whether this ‘resource’ 
will be available after it has been released, or would it be more efficient for the project to place the 
resource on a short-term contract? The project manager will only be able to make such efficiency 
decisions once resource estimating has taken place across the whole project. 


8.3.4 Costs 


Detailed cost estimates can be made from the work packages (in which resources and the durations 
these resources are required for, has been identified) along with any other miscellaneous costs 
identified. Costs typically fall into a number of categories, as outlined in Table 8.3. 


Table 8.3 Common categories of costs 


Fixed direct costs Fixed indirect costs Variable direct costs Variable indirect costs 

Direct costs are costs that Indirect costs cannot be Variable costs ‘change’ with Variable indirect costs arise 

are directly attributable to directly attributed to the the amount of some quantity as a result of an indirect 

the project. project but usually occuras being costed. cost being attributed to the 

They are chargeable toa a result of a direct cost. project. 

specific work package. Sometimes referred to as Sometimes referred to as 
G&A costs (general and G&A costs (general and 
administrative costs). administrative costs). 

Examples: Examples: superannuation Examples: costs of IT support: Examples: a leave-loading 

+ concrete payments for hired staff; every time the project calls for hired staff (which is 

+ purchase of personal office maintenance costs the service desk they are obviously affected by 

computers as a result of leasing/ charged for the call, butthe the amount of holiday 

+ hiring of staff purchasing premises. final cost depends on how taken; the amount of time 

* project manager's salary many calls are made; mobile cleaning crews spend on 

+ lease of office space phone charges fora project cleaning). 

+ bonus payments team of 180 people. 


The total project cost estimate can be broken down in this fashion to focus the control process and 
improve decision-making (i.e. it is clearer to see where costs are being allocated to at a high level). 
Often organisations will have their own structure around how the project should account. for costs 
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incurred e.g. a ‘chart of accounts’ or ‘project accounting codes’. The project manager should seek 
advice therefore from the finance department about how to allocate and record costs within their 
project environment. (Refer to Chapter 1@ for further discussion on this topic.) 


8.4 ESTIMATING GUIDELINES FOR RESOURCES, 
TIME AND COST 


The process of estimating must be clearly understood to ensure all aspects have been considered and 
that crucial elements are not overlooked. A commonly asked question about estimating is simply: 
‘Where do I start?’ The simple answer is: ‘With resources at the work package level’. 

Figure 8.2 illustrates one of the author's (Pearson's) ‘default’ mode of thinking when it comes to 
estimating at the task and work package level. 

Managers recognise time, cost and resource estimates must be accurate in order to gain an 
understanding of (in the Initiating stage), be able to refine (in the Planning stage) and track (in the 
Executing stage) the performance of the project. However, there is substantial evidence to suggest 
that poor estimates are a major factor in many projects that have failed. Therefore, every effort should 
be made to see that initial estimates are as accurate as possible. Making a choice to not produce 
estimates leaves a great deal to luck, and this scenario would not be acceptable to most professional 
project managers and most modern organisations. 

Even though a specific project will not have been carried out before due to its uniqueness in some 
way, a project manager can follow eight guidelines (given below) to develop useful work package 
estimates: 


1. Responsibility: At the work package level, estimates should be made by the person(s) most 
familiar with the task. Draw on their subject matter expertise (the reason these stakeholders 
are termed subject matter experts or SMEs). Except for super-technical tasks, those who 
are responsible for getting the job done, on schedule and within budget, are usually first-line 
supervisors or technicians who are experienced and familiar with the type of work involved. 
These people generally will not have a preconceived duration for a deliverable in mind. They will 
instead give an estimate based on their experience and best judgement. A secondary benefit of 
using those who are responsible for getting the job done is the potential buy-in from them that 
is gained when they see that the estimate materialises when they implement the work package. 
If those involved are not consulted, it will be difficult to hold them responsible for a failure to 
achieve the estimated time—if they are subsequently allocated the task or work package to 
deliver. Finally, drawing on the expertise of team members who will be responsible helps to build 
communication channels early. 


2. Use several people to estimate: It is well known that a time, cost or resource estimate usually has 
a better chance of being reasonable and realistic when several people with relevant experience 
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and/or knowledge of the task are consulted. It is, of course, true that people will each bring 
different biases to the table, based on their unique work and life experiences, but a discussion of 
individual differences in their estimates can actually lead to a consensus (and tends to eliminate 
extreme estimate errors). 


Normal conditions: When task time, cost and resource estimates are determined, they will have 
been based on certain assumptions. Estimates should be based on normal conditions, efficient 
methods and a normal level of resources. ‘Normal conditions’ are sometimes difficult to discern, 
but it is necessary to have a consensus in the organisation as to what normal conditions means 
in the project. If the normal workday is eight hours, then the time estimate should be based on 
an eight-hour day; if the normal workday is two shifts, then the time estimate should be based 
on a two-shift workday. A time estimate should reflect efficient ‘normal methods of use’ for 

the resources that are to be available. The time estimate should represent the normal level of 
resources, people or equipment. For example, if three programmers are available for coding, 

or two road graders are available for road construction, the time and cost estimates should be 
based on these normal levels of resources (unless it is anticipated the project will change what 
is currently viewed as normal). Possible conflicts in the demand for resources on parallel or 
concurrent activities should not be considered at this stage. The need for adding resources will be 
examined when resource scheduling is discussed in Chapter 9. 


Time units: The specific time units to be used should be selected early in the Initiating stage 

of the project. All task time estimates need to use consistent time units. Estimates of time must 
consider whether ‘normal time’ is represented by calendar days, workdays, work weeks, person 
days, single shift, hours, and so on. In practice, ‘workdays’ is the dominant choice for expressing 
task duration. However, in projects such as a heart transplant operation, minute increments 
would probably be more appropriate to use as a time unit. An example of a project that is known 
to have used minutes as the time unit involved the movement of patients from an old hospital 

to anew purpose-built hospital across town. Since the project encompassed moving patients 

for whom a move could be lifeendangering, minutes were used to ensure patient safety and 
emergency life-support systems were on standby in case these were needed. The point is, network 
analysis requires a standard unit of time. When software programs allow more than one option, 
some notation should be made of any variance from this standard unit. If the standard unit of 
time is say, a five-day workweek, and the estimated activity duration is in calendar days, then 
time must be converted to the normal work-week. 


Independence: Estimators should treat each task as being independent of other tasks that might 
be integrated by the WBS. First-line managers usually consider tasks independently; this is good. 
‘Top’ managers are prone to aggregating many tasks into a onetime estimate and then they 
deductively make the individual task time estimates add to the total. If tasks are in a chain and 
performed by the same group or department, it is best not to ask for all the time estimates in the 
sequence at once. This is to try to avoid the tendency for a planner or a supervisor to look at 

the whole path and then try to adjust individual task times in the sequence to meet an arbitrarily 
imposed schedule or some rough ‘guesstimate’ of the total time for the whole path or segment 

of the project. This tendency does not reflect the uncertainties of individual activities, and 
generally results in optimistic task time estimates. In summary, each task time estimate should be 
considered independently of other activities. 

Contingencies: The concept of contingency is further discussed in Chapter 1@. All those involved 
in estimating should be aware of the ground rules around when and how contingency is to be 
considered. 

Carrying out a risk assessment of the estimate helps to avoid sur prises: It.is obvious that 

some tasks will carry more time and cost risks than others. For example, introduction of a new 
technology usually carries more time and cost risks than a proven technology that has been 
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implemented hundreds of times. Simply identifying the degree of risk lets stakeholders consider 
alternative methods and alter process decisions. (Refer to Chapter 17 for further discussion on 
project risk.) 

8. Cost of quality (Co@): Quality affects many areas of a project and needs to be considered when 
estimating. Quality will affect the choice of equipment used, the people utilised, and ultimately 
will affect ‘what’ and ‘who’ is used in the project. Highe rquality materials and resources (in 
general) will affect who and what services are considered in estimating. Usually there is a higher 
cost to the project when higher-quality (more-expensive resources) are used. For example, an 
estimate provided by lowercost providers will be lower than if higher-end (higher-quality) 
providers are used—but there again the quality expectations from the lower-cost provider would 
also be lower! Chapter 12 provides a more extensive discussion on quality and how quality affects 
many aspects of a project. 


8.5 TOP-DOWN VERSUS BOTTOM-UP ESTIMATING 


Since the process of estimating costs money, deciding how much time and detail to devote towards 
the process can be difficult. When considering estimating, you (as a project manager) may be faced 
with statements such as these: 


@ ‘Rough order of magnitude is good enough. Spending time on detailed estimating wastes money!’ 


@ ‘Time is everything; our survival depends on getting there first! Time and cost accuracy is not an 
issue.’ 


m ‘The project is internal; we don't need to worry about cost.’ 
m ‘The project is so small; we don't need to bother with estimates. Just do it” 


m ‘We were burned once; I want a detailed estimate of every task by the people responsible.’ 


However, there are sound reasons for using ‘top-down’ or ‘bottom-up’ estimates and Table 8.4 
depicts conditions that suggest when one approach might be preferred over another. 


Table 8.4 Conditions that may sway the choice of top-down or bottom-up estimating 


Condition Top-down estimates Bottom-up estimates 
Strategic decision-making x 

Cost and time important x 
High uncertainty (risk) x 

Internal, small project x 

Fixed-price contract x 
Customer wants details x 
Unstable scope x 

Public money being spent x 
Public—private (PFI) projects x 


Referring to Figure 8.3. Top-down estimates are usually derived from someone who uses 
their subject matter experience and/or personal sources of information to determine the project's 
duration, typical resources needed and, therefore, total cost. These estimates are sometimes carried 
out at a whole-of-project level, or maybe at the first two levels of the WBS. These estimates are 
often made by managers who have very little knowledge of the processes of project management. 
For example, in a mayoral speech, the mayor of a major city exclaimed that a new law building 
would be constructed at a cost of A$23 million and would be ready for occupancy in two years. 
Although the mayor probably asked for an estimate from someone, it is not clear who this came 
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from—there is every chance (but you hope not) that it came froma lunch-time meeting with a local 
contractor who wrote an estimate (or guesstimate) on a paper napkin! This is of course an ‘out there’ 
example, but in a relative sense, this type of scenario is often played out in reality, raising questions 
such as: Do these estimates represent lowcost, efficient methods? Do the top-down estimates of 
project time, cost and resources, become a selffulfilling prophecy, in terms of setting time, cost and 
resource parameters? 

If possible and practical, the project manager will want to push the estimating process down to 
the work package level for bottom-up estimates, yet establish low-cost, efficient methods for doing 
this. This process can take place after the project has been defined in detail. Good sense suggests 
that project estimates should come from the people who are most knowledgeable about the estimate 
needed. Using several people who have relevant experience with the task can also help to improve 
time, cost and resources estimates. 

A bottom-up approach at the work package level can serve as a check on cost elements in the 
WBS by rolling up the work packages and associated cost accounts to major deliverables. Similarly, 
resource requirements can be checked. Later, the time, resource and cost estimates from the work 
packages can be consolidated into project schedules, resource schedules and the project budget; all 
of which are used to control the project during the Executing stage. The bottom-up approach also 
provides the customer with an opportunity to compare the low-cost, efficient. method with any 
imposed restrictions. For example, if the project completion duration is imposed at.two years and the 
bottomup analysis tells you the project will take three years, the client can now consider the trade-off 
of the low-cost method versus compressing the project to two years or, in rare cases, cancelling the 
project. Similar tradeoffs can be compared for different levels of resources or increases in technical 
performance. 
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SNAPSHOT FROM PRACTICE Macmahon—Hope Downs rail project 





Macmahon Holdings, a Perth-based mining services been identified with earthworks productivities 
and construction company, announced that its CEO of and the order in which the work must be now 
12 years was stepping down and also slashed its profit performed to meet the revised program, he said. 
forecast for the year (2012—13). But why? ‘These issues mean that additional costs 


will be incurred to ensure the client’s schedule 
for track laying is met and that the project is 
substantially completed in the first half of this 
financial year’ (Wilson-Chapman 201 2). 


Macmahon chairman Ken Scott-MacKenzie said 
the company identified a number of issues with its 
Hope Downs 4 rail earthworks project that resulted 
in delays and additional costs to meet Rio Tinto’s 


track laying deadlines. Where the failure in estimating actually occurred was 
The $99 million contract was scheduled for not made clear, but the example exemplifies clearly the 

completion in August or September this year costs of not attending to estimating correctly. Where do 

[2012], but will now cost the company about you think the process fell down? 

$500,000 a day until completion, according to ——— 

Mr Scott-MacKenzie. Source: Wilson-Chapman A 2012, ‘Macmahon CEO gone, shares halve’, 


4 ji i News Limited, www.news.com.au/business/companies/macmahon-shares- 
Following the management review ofthe Hope plummeton-downgrade/story-fnda 1bsz-1226477144064, accessed 


Downs 4 project a number of additional issues have October 2012 


The assumption is that any movement away from the low-cost, efficient method will increase costs 
(e.g. overtime). The preferred approach in defining the project is to make rough top-down estimates, 
develop the WBS/OBS, make bottom-up estimates, develop schedules and budgets, and reconcile 
differences between top-down and bottom-up estimates. Hopefully, these steps will be done before 
final negotiation with either an internal or external customer. 

In conclusion, the ideal approach is for the project manager to allow enough time for both the top- 
down and bottomup estimates to be worked out, so a complete plan (based on reliable estimates) 
can be offered to the customer. In this way, false expectations are minimised for all stakeholders and 
negotiation is reduced. (Review Snapshot from Practice: Macmahon—Hope Downs rail project.) 


8.5.1 A hybrid approach: Phase estimating 


The hybrid approach begins with a top-down estimate for the project (typically in the Initiating phase), 
and then refines estimates for phases of the project in the Planning phase. Some projects, by their very 
nature, cannot be rigorously defined because of the uncertainty of design or the final product. These 
projects are often found in aerospace projects, IT projects, new technology projects, construction 
projects and research projects, where design is incomplete and the previous phase informs the next 
phase of the project. In these projects, phase or lifecycle estimating is frequently used. 

Phase estimating is used when an unusual amount of uncertainty surrounds a project and 
it is impractical to estimate times and costs for the entire project. Phase estimating uses a two- 
estimate system over the life of the project. A detailed estimate is developed for the immediate 
phase and a macro (high-level) estimate is made for the remaining phases of the project. Figure 8.4 
depicts the phases of a project and the progression of estimates over its life (the arrows represent 
the change in levels of detail in estimating made). As an example, when the project need (Business 
Case) is determined, a macro estimate of the project cost, duration and resources is made, so 
analysis and decisions can be made. Simultaneously, a detailed estimate is made for deriving 
specifications (Initiating) and a macro estimate for the remainder of the project. As the project 
progresses and specifications are solidified, a detailed estimate for design (Planning) is made and 
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a macro (highlevel) estimate for the remainder of the project is calculated. Clearly, as the project 
progresses through its life cycle and more information is available, the reliability of the estimates 
should be improving. 

Phase estimating is preferred by those working on projects where the final product is not known 
and the level of uncertainty is significant—for example, the integration of internet technology into 
home appliances (the internet of things (IoT)). The commitment to cost and schedule is only necessary 
over the next phase of the project and commitment to unrealistic future schedules and costs based on 
poor information is avoided. This progressive macro/detailed method provides a stronger basis for 
using schedule and cost estimates to manage progress during the next phase. 

Unfortunately, your customer (internal or external) will likely be pressing for an accurate estimate 
of time, cost and resource (commitment) the moment the decision is made to implement the project. 
Additionally, the customer who is paying for the project often perceives phase estimating as a blank 
cheque, because costs and schedules are not firm over most of the project life cycle beyond the current 
phase. Even though the reasons for phase estimating are sound and legitimate, most customers have 
to be persuaded of its legitimacy. A major advantage for the customer is the opportunity to change 
features, re-evaluate or even cancel the project in each new phase. In conclusion, phase estimating 
is very useful in projects that possess huge uncertainties concerning the final nature (shape, size, 
features) of the project. 


8.6 METHODS FOR ESTIMATING PROJECT 
RESOURCES, DURATIONS (TIME) AND COSTS 


This next section reviews a number of commonplace estimating tools and techniques that are 
used to carry out estimating durations (time), costs and resources. These tools and techniques are 
commonly found in a wide range of disciplines (e.g. from project management. to engineering). 
Table 8.5 illustrates the commonality between tools and techniques across the three knowledge areas 
of time, costs and resources in the Project Management Institute’s A Guide to the Project Management 
Body of Knowledge (PMBOK) (PMI 2017). 

Each of these tools and techniques in Table 8.5 with some additional techniques will now be 
described with examples. 
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Table 8.5 Estimating techniques (and the PMBOK knowledge areas) 


Expert judgement 
Analogous estimating 
Parametric estimating 
Three-point estimating 
Bottom-up estimating 
Data analysis 


Decision-making 


Expert judgement 
Analogous estimating 
Parametric estimating 
Three-point estimating 
Bottom-up estimating 
Data analysis 
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Analogous estimating 
Parametric estimating 
Bottom-up estimating 
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= Project Management Information Project Management Information 
System System 


8.6.1 Expert judgement 


Similar to the consensus approach, this is where subject matter experts (SMEs) are drawn into the 
estimating process. As an SME for a particular subject area, these people bring a vast knowledge base 
of past experience to the project. Using SMEs to estimate components of the project therefore can 
potentially provide years of insights and experience on the item being estimated. Expert judgement 
can therefore prove to be a very useful estimating resource—providing information that the project 
manager or others in the project team would otherwise not have access to. For example, as project 
manager you are often (although you should not need to be) an SME. On a large office relocation 
project, one of the authors brought in a specialist cabling company to figure out. the best way to 
provide flexible cabling layouts for phone and multiple data points per seat. The specialist cabling 
company made the recommendation to use raised floors, with moveable data/phone housing tiles that 
were placed on longer than normal cable runs: this allowed the floor space and density of phones/ 
cables to be altered to infinite combinations by simply lifting floor tiles. Without the expert judgement 
of the specialist cabling company, the best solution and therefore cost may not have been arrived at 
so efficiently. 


8.6.2 Analogous method 


‘Analogous’ means ‘similar’ or ‘alike’ in such a way as to permit the ‘drawing of an analogy’ (a 
similarity between the alike features of two things). When applied to project management, we are 
usually comparing the estimates of the project (or components of a project) with past similar projects, 
so as to inform and formulate our estimate. The analogous estimating method requires that. good 
up-to-date historical data is available to make comparisons against. 

This method is suitable for use where the current project closely follows past projects in features 
and costs. Analogous estimates can be made quickly with little effort and with reasonable accuracy. 
This method is very common in projects that are relatively standard but have some small variation or 
customisation. When comparing, it is advised to check how current the comparison project is—outof- 
date project comparison will lead to inaccurate estimates. For example, a current project has to build 
a two-car shed with workshop for a house build project. Instead of spending time obtaining quotes 
for the work, the project manager could look at previous similar projects. If the twocar shed with 
workshop cost A$23 500 a year ago on a similar project, a figure close to this would be used on the 
current project. By using analogy, we have removed guess work and applied facts based on a previous 
known project. 
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8.6.3 Parametric estimating 


Parametric estimating is a technique where data on various parameters of a previous project are 
used to make a current estimate of the work to be carried out. The relationship between the historic 
parameters (such as weight, size, cost, complexity, manpower) are used to estimate the current. 
requirements. 

For example, contractors frequently use the number of square metres to estimate the cost and time 
involved in building a house: that is, a house of 50 square metres might cost $1000 per square metre 
(50 square metres X $1000 per square metre equals $500 000). Likewise, knowing the square metres and 
dollars per square metre, experience suggests it should take approximately 100 days to complete. Just 
as parametric techniques such as cost per square metre can form the source of top-down estimates, 
the same technique can be applied to specific tasks at the work package level. For example, as part of 
a Microsoft® Office conversion project, 36 different computer workstations needed to be converted. 
Based on past conversion projects, the project manager determined that on average, one person could 
convert three workstations per day. Therefore, the task of converting the 36 workstations would take 
three technicians four days. Similarly, to estimate the wallpapering allowance on a house renovation, 
the contractor figured a cost of $5 per square metre of wallpaper and $2 per metre to install it, for a 
total cost of $7. By measuring the length and height of all the walls they were able to calculate the 
total area in square metres and multiply it. by $7. 


8.6.4 Three-point estimate 


The PERT method (three-point estimate) has become a popular way to arrive at an average, based 
on three estimates. The PERT formula considers three estimates: a Low (optimistic) estimate, an Average 
(most likely) estimate, and a High (pessimistic) estimate. The formula for the three-point estimate is: 


Optimistic + (4 x Most likely) + Pessimistic 
6 





When applied to the same data as the range method, the results can be seen in Figure 8.5. The PERT 
formula typically results in a slightly higher estimate than would be achieved if the ‘most likely’ option 
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was selected. However, if all of these (typically) small increases were taken across the whole project, 
the result could be a noticeably higher overall project cost and/or time estimate for the project. The 
challenge here is in obtaining the number of estimates required, and the time involved in obtaining 
them. Overall, this approach is seen to provide a more realistic estimate. 


8.6.5 Consensus methods (decision-making voting) 


This method simply uses the pooled experience (of managers) to estimate total project duration and 
cost. This typically involves holding a meeting where experts discuss, argue and ultimately reach a 
decision as to their ‘best guess’ estimate. Firms seeking greater rigour however will use the Delphi 
method to make these macro estimates. It is important to recognise that such preliminary top-down 
estimates are a rough cut only and typically occur in the Initiating stage of the project. These top- 
down estimates are helpful in an initial development of a complete plan. However, such estimates 
are sometimes significantly off the mark because little detailed information is gathered. At this level, 
individual work items are not identified or, in a few cases, the top-down estimates are not realistic 
because top management ‘wants the project’. Nevertheless, this type of initial top-down estimate can 
be helpful in determining whether the project warrants more formal planning, which would include 
more detailed estimates. Look out for potential scenarios where macro estimates made by senior 
managers are dictated to lower-level managers, who then feel compelled to accept the estimates even 
if they believe resources are inadequate. 

Although the authors prefer to avoid the top-down approach towards estimating if possible, we have 
(from time to time) witnessed surprising accuracy in this approach towards estimating project duration 
and cost—some examples being for building a manufacturing plant, building a distribution warehouse, 
developing air control for skyscraper buildings, and in road construction. However, we have also 
witnessed some horrendous miscalculations, usually in areas where the technology is new and unproven. 
Top-down methods can be useful, if experience and judgement have been accurate in the past. 


8.6.6 Alternative analysis (a type of data analysis) 


Alternative analysis considers the different. alternatives that provide the same outcomes/outputs 
of the project. Alternative analysis can be applied at a higher level in the project to determine which 
of a set of options could be the best choice, for example, whether an organisation buys in a software 
package to manage payroll, employs a service company to provide the payroll processing, or the 
project develops a customised software solution in-house. Similarly, an alternative analysis might be 
considered in a bottomup approach when estimating a discrete piece of work, by simply considering, 
‘What alternatives to achieving the same end-state exist?’ 

Take, for example, the refurbishment of an ore processing plant: the project has work packages 
defined that cover the refurbishment of a number of silos. What potential alternatives does the project 
manager have? 


1. Erect scaffold towers, clean and prepare surfaces, paint, tear down scaffold towers, at a cost of 
A$3.5million. 


2. Build a switch-out silo and switch out each silo in turn, enabling the other silos to remain in 
service, ata cost of A$2.5million. 


3. Use a customdesigned ‘Zift to refurbish each silo in situ, at a cost of A$1.5million. 


This is often why project managers go to tender when looking at unusual pieces of work. 


8.6.7 Reserve analysis 


Reserve analysis is used to determine the amount of contingency and management reserve needed 
for the project. Refer to Chapter 10 for a detailed explanation of this technique. 
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8.6.8 Cost of quality 


Chapter 12 discusses the impacts of both the cost of quality (CoQ) and cost of poor quality (CoPQ) and 
how these impact the discussion of quality. Generally, the higher the level of quality specified by the 
customer, the more increase in costs there will be due to additional quality activities, more expensive 
raw materials/components and additional quality control checks required to ensure compliance with 
the high level of specifications. 


8.6.9 Vendor bid analysis 


Again, as with some of the other methods, the vendor bid method can be applied in both a top-down 
and bottom-up approach. Although mostly used to obtain quotes for work packages in a bottom-up 
approach, it can also be applied to a complete branch of the WBS at a higher level (this may be relevant 
when a whole part of the project is to be contracted out or outsourced in some form). In this method, 
vendors are provided with the work package details and asked to provide details of costs and timing. 
Depending on which stage the project is at, this may influence the type of information requested. For 
example, during the project Initiating stage a request for information (RFI), or a request for quote 
(RFQ), might be appropriate methods for approaching vendors; however, as the project moves into the 
Planning stage, a request for tender (RFT) would be a more appropriate format to employ. Chapter 18 
details the differing types of tender that are available to the project manager. 


8.6.10 Estimating tools and systems (project management 
information systems) 


The best way to improve estimates is to collect and archive data on past project ‘estimates’ (planned 
values) and ‘actuals’. Saving historical data (for both estimates and actuals) provides a knowledge 
base of information that can be drawn upon to help improve project cost, time and resource 
estimations. Creating an estimating database is a ‘best practice’ approach, supported by leading 
project management organisations (such as PMI, APM and PRINCE2). Companies that are disciplined 
about their estimating approach will often capture large amounts of data over a long time, and use this 
data to produce estimates of work. Internal estimating tools typically reside within spreadsheets and 
databases: an example of this might be an energy utility company that has vast amounts of historical 
data on completed projects, down to a work package level in the organisation—each work package 
successfully captures details of the resources that were actually used, the durations they were needed 
for, and their associated costs. This data can therefore be mined to inform estimate data for standard 
jobs in current and future projects. 

Externally, many companies provide simple online estimating tools for their customers to use to 
generate estimates (thus saving the company time and money in having to perform estimating tasks 
for the customer). These types of tools are often seen on equipment hire websites, where the customer 
selects the required equipment, nominates the duration of the hire period, the insurance level required 
and other selections as appropriate, and the estimating tool then provides them with an online quote. 

Two key rules to remember when setting up estimating tools are: 1) ensure the data is maintained 
(remember the saying ‘rubbish-in, rubbish-out!’) and 2) allow for variables. For example, what. if (in 
the case of the utility company example) the geological make-up of the ground for which a quote was 
prepared was not considered in the estimation tool? If normal ground conditions were assumed in the 
estimating tool, how much would the estimate be out if rock was encountered? 


8.6.11 Lessons-learned 


Mining lessons-learned from previous projects can be helpful in influencing not only ‘how’ estimating 
is to be approached in your current project, but also ‘what’ is be estimated. Some lessons-learned will 
be related to the ‘how’, or the process, of estimating. These lessons could be about developing and 


PART 3 DEFINING AND MANAGING PROJECTS 


updating ‘sub-processes’ such as the one indicated in Figure 8.2, earlier in this chapter. If we can be 
more efficient about ‘how’ we estimate, then valuable time and resources may be freed up to allow a 
more concentrated focus on the ‘what’ of estimating. For example, a lesson-learned from a previous 
project indicated that GST (tax) and shipping and handling costs (among other miscellaneous costs) 
were frequently being omitted from estimates. The project team therefore collectively brainstormed a 
mandatory checklist that had to be signed by the project team member to verify completeness as part 
of quality control. 

Other lessons will relate to the ‘what’ component of what we are estimating. A lesson-learned from 
a previous project used in this text indicates that in a ‘three bedroom plus garage house-build’, the use 
of environmentally friendly products in its construction increased build costs by 35 per cent across the 
entire project. Learning from past projects (whether the lesson is positive or negative) is an essential 
exercise project managers must leverage. 


8.6.12 Function point methods for software and system projects 


In the software industry, software development projects are frequently estimated using weighted 
macro variables called function points, or major parameters such as number of inputs, number 
of outputs, number of enquiries, number of data files and number of interfaces. These weighted 
variables are adjusted by adding in a complexity factor. The total adjusted count provides the basis 
for estimating the labour effort and cost for a project (usually using a regression formula derived from 
data of past projects). Refer to online resource—Function points. 


8.6.13 Template methods 


Ifthe project is similar to past projects, then the costs from past projects can be used as a starting point 
for the new project. Differences in the new project can be noted and past times and costs adjusted to 
reflect these differences. For example, a ship repair dry-dock firm has a set of standard repair projects 
(e.g. templates for overhaul, electrical, mechanical) that are used as starting points for estimating the 
cost and duration of any new project. Differences from the appropriate standardised project are noted 
(for times, costs and resources) and changes are made. This approach enables the firm to develop a 
potential schedule, estimate costs and develop a budget in a very short time-span. Development of 
such templates in a database can quickly reduce estimate errors. These may appear as a ready-made 
bill of material (BoM) in some organisations. (Refer to Chapter 18.) 


8.6.14 Range estimating 


Let's start by first considering when range estimating should be used: range estimating works 
best when work packages have significant uncertainty associated with the time, cost or resource 
dimensions involved for completing the work package. 

If the work package is routine and carries little uncertainty, then using the person who is most 
familiar with the work package to estimate is usually the best approach. They will either know 
durations (time), costs and resources from past experience, or know where to find this information 
and so should be able to estimate work package durations (time), costs and resources relatively 
easily. However, when work packages have significant uncertainty associated with time (duration), 
cost and resources, it is prudent to have a policy that requires three estimates to be given—low’, 
‘average’ and ‘high’. The ‘low’ to ‘high’ estimates give a range within which the ‘average’ estimate will 
fall. Determining the ‘low’ and ‘high’ estimates for the activity will be influenced by factors such as 
complexity, technology, newness and familiarity. 

How are estimates obtained? Since range estimating works best for work packages that have 
significant uncertainty, having a group determine the ‘low, average and high’ cost or duration gives 
the best results. Group estimating tends to refine extremes by bringing more evaluative judgments to 
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Description Low Average High Range Risk 
ID Estimate Estimate Estimate Level 
Days Days Days Days 
102 Approval 1 1 3 2 low 
11 103 Design packaging 4 12 8 medium 
|12| 104 1D potential customers 14 2 35 21 high 
13| 105 Design bottle logo 5 id 10 5 low 
|14| 106 Contract kiosk space 8 o 15 ká medium 
15| 107 Construct kiosk 4 4 8 4 medium 
16 108 Design fair brochure 6 7 12 6 high 
1A 109 Trade journal advertising 10 12 15 5 medium 
18 110 Production test 10 14 20 10 high 
[19| 111 Produce to inventory 5 5 10 5 high 
20| 112 Business card scanner hookup T 2 3 2 low 
21 113 Video hook up 2 2 4 2 medium 
22 114 Event rehearsal 2 2 5 3 high 


the estimate about potential risks. The judgement of others in a group helps to moderate perceived 
extreme risks associated with a time or cost or resource estimate. Involving others in making estimates 
gains buyin and also credibility for the estimate. Figure 8.6 presents an abridged estimating template 
using three time estimates for work packages developed by a cross-functional group(s) of project 
stakeholders. The group estimates show the low, average and high values for each work package. 
The risk level column is the group's independent assessment of the degree of confidence that the 
actual time required will be very close to the estimate. In a sense, this number represents the group's 
evaluation of many factors (e.g. complexity, technology, experience) that might impact the average 
time estimate. 

How do you use the estimate? Group range estimating gives the project manager and owner an 
opportunity to assess the confidence associated with project times (and/or costs). This approach 
helps to reduce surprises as the project progresses. The range estimating method also provides a 
basis for assessing risk, managing resources and determining the project contingency fund. Range 
estimating is popular in software and new product projects, where up-front requirements are ‘fuzzy’ 
and not well known. Group range estimating is often used with phase estimating (discussed next). 
Obtaining accurate estimates is a challenge, however. Committed organisations accept the challenge 
of coming up with meaningful estimates and invest heavily in developing their capacity to do so. 
Accurate estimates reduce uncertainty and support a discipline for effectively managing projects. See 
Table 8.6 for a summary of the differences between top-down and bottom-up estimates. 


Table 8.6 Estimating techniques, in relation top-down and bottomup estimating 





Tool/Technique Approach 
Top-down Bottom-up 
Expert judgement Applied to the top levels of the WBS. Applied to items within each work package, 
to compare/validate against other methods. 
Analogous estimating Applied to the top levels of the WBS. Applied to items within each work package, 
or at a work package level. 
Parametric estimating Applied to the top levels of the WBS. Applied to items within each work package, 


or at a work package level. 


Continued 
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Continued 


Three-point estimate 


Consensus methods and Delphi 
Alternative analysis 


Reserve analysis 


Cost of quality 
Vendor bid analysis 


Estimating tools and systems 


Function point methods for software and 
system projects 

Template methods 

Range estimating 

Lessons-learned 


Can be applied to a section of the WBS when 
used in conjunction with other techniques 
such as vendor bid analysis. 


Applied to the top levels of the WBS. 


Applied to the approach taken to accomplish 
the project at higher levels of the WBS. 


Contingency applied to the whole project 
level of the WBS or the control level. 


Applied to the whole project. 


On a section of the WBS which may be 
outsourced in its entirety. 


Applied at the project level from previous 
projects’ lessons. 


Applied to items within each work package. 


Applied to items within each work package. 


Applied to items within each work package, 
or at a work package level. 


Contingency applied at the task and work 
Package level. 


Applied at the task and work package level. 


Applied to items within each work package, 
or at a work package level. 


Applied to items within each work package, 
or at a work package level. 


Applied to items within each work package, 
or at a work package level. 


Well-defined jobs within a work package. 
Applied to items within each work package. 





Applied at the task and work package level 
from previous projects’ lessons. 


8.7 ADDITIONAL ESTIMATING CONSIDERATIONS 


8.7.1 Level of detail in estimating 


Top management interests usually centre on the total project and major milestone events that mark 
major accomplishments, for example ‘Build oil platform in the North Sea’ or ‘Complete prototype’. 
Middle management might centre on one segment of the project or on one milestone. Frontline 
managers’ interests may be limited to one task or work package. One of the benefits of the WBS is 
the ability to aggregate task level information, so each level of management can have the kind of 
information that is necessary in order to make decisions. Getting the level of detail in the WBS to 
match management needs for effective implementation is crucial; yet this delicate balance is difficult. 

The level of detail in the WBS varies with the complexity of the project, the need for control, 
the project size, its cost, duration, resource commitments and other factors. If the structure reflects 
excessive detail, there is a tendency to break the work effort into departmental assignments. This 
tendency can become a barrier to success however, since the emphasis will be on departmental 
outcomes, rather than on deliverable outcomes. Excessive detail also means more work, which may 
not be required given the factors noted previously. Note that if the level of the WBS is increased by one, 
the number of cost accounts may increase geometrically. On the other hand, if the level of detail is not 
adequate, an organisational unit may find the structure falls short of meeting its needs. Fortunately, 
the WBS has builtin flexibility. Participating departments may expand their portion of the structure 
to meet their special needs. For example, the engineering department may wish to further break down 
work on a deliverable into smaller packages by ‘electrical’, ‘civil’, and ‘mechanical’. Similarly, the 
marketing department may wish to break a new product promotion into ‘TV’, ‘radio’, ‘periodicals’ and 
‘newspapers’. 


8.7.2 Refining estimates 


As described earlier, detailed work package estimates are aggregated and rolledup by deliverable 
to control packages, and subsequently to the project level to provide the total planned cost of the 
project. Similarly, estimated durations are entered into the project schedule to establish and determine 
the overall duration of the project. Experience tells us that for many projects, ‘total’ estimates do not 
materialise, and the actual costs and schedule of some projects significantly exceed original work 
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package estimates. In order to compensate for the difficulty of obtaining cost. and schedule estimates, 
some project managers adjust total costs by some multiplier (e.g. total estimated costs x 1.20). The 
practice of adjusting (padding) original estimates by 20, or even 100 per cent, begs the question of 
why? After investing so much time and energy on detailed estimates, why could the numbers be 
so far off? There are a number of reasons for this, most of which can be traced to the estimating 
process itself and the inherent uncertainty of predicting the future. Some of these potential reasons 
are outlined below: 


Interaction costs are hidden in estimates: According to the guidelines, each task estimate is 
supposed to be done independently. However, tasks are rarely completed in a vacuum. Work 
on one task is dependent upon prior tasks, and the hand-offs between tasks require time and 
attention. For example, people working on prototype development need to interact with design 
engineers after the design is completed, whether to simply ask clarifying questions or to make 
adjustments in the original design. Similarly, the time necessary to coordinate activities is 
typically not reflected in independent estimates. Coordination is reflected in meetings and 
briefings as well as time necessary to resolve disconnects between tasks. Time, and therefore 
cost, devoted to managing interactions rises exponentially as the number of people and different 
disciplines involved increases on a project. 


Em Normal conditions do not apply: Estimates are supposed to be based on normal conditions. 
While this is a good starting point, it rarely holds true in real life. This is especially true when 
it comes to the availability of resources. Resource shortages, whether in the form of people, 
equipment or materials, can extend original estimates. For example, under normal conditions, 
four bulldozers are typically used to clear a certain site size in five days, but the availability of 
only three bulldozers would extend the task duration to eight days. Similarly, the decision to 
outsource certain tasks can increase costs as well as extend task durations, since time is added to 
acclimatising outsiders to the particulars of the project and the culture of the organisation. 


E Things go wrong on projects: Design flaws are revealed after the fact, extreme weather 
conditions occur, accidents happen, and so forth. Although you shouldn't plan for these risks to 
happen when estimating a particular task, the probability and impact of such events needs to be 
considered as part of the risk analysis. Refer to Chapter 17. 


E Changes in project scope and plans: As one gets further and further into the project, a project 
manager obtains a better understanding of what needs to be done to accomplish the project. This 
may lead to major changes in project plans and costs. Likewise, if the project is a commercial 
project, changes often have to be made midstream to respond to new demands by the customer 
and/or competition. Unstable project scopes are a major source of cost overruns. While every 
effort should be made up-front to nail down the project scope, it is becoming increasingly difficult 
to do so in our rapidly changing world. 


The reality is that for many projects, not all of the information needed to make accurate estimates 
is available, and it is impossible to predict the future. The dilemma is that without solid estimates, the 
credibility of the project plan is eroded. Deadlines become meaningless, budgets become ‘rubbery’ and 
accountability becomes problematic. 

Challenges similar to those described above will influence the final time, cost and resource 
estimates. Even with the best estimating efforts, it may be necessary to revise estimates based 
on relevant information prior to establishing a baseline schedule and baseline budget. Effective 
organisations adjust estimates of specific tasks once the risks, resources and particulars of the 
situation have been more clearly defined. They recognise that the rolled up estimates generated from 
a detailed estimate based on the WBS are just a starting point. As they delve further into the project 
planning process, they make appropriate revisions, both in the time, cost and resource commitments 
of specific activities. They factor the final assignment of resources into the project budget and project 
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schedule. For example, when they realise that only three instead of four bulldozers are available 
to clear a site, they adjust both the time and cost of that activity. They adjust estimates to account 
for specific actions to mitigate potential risks on the project. For example, to reduce the chances of 
design code errors, they would add the cost of independent testers to the schedule and budget. Finally, 
organisations adjust estimates to take into account abnormal conditions. For example, if soil samples 
reveal excessive ground water, they accordingly adjust foundation costs and times. 

There will always be some mistakes, omissions, and adjustments that will require additional 
changes to estimates. Fortunately, every project should have a change management system in place 
to accommodate these situations, and any impact on the project baseline. 


Quality, realistic, and reliable resource, time and cost estimates are the bedrock of project credibility. Past experience 
(including lessons-learned from previous projects) is one of the best starting points for estimation. Factors that must 
be considered in estimating include: 


m The management of expectations around the level of accuracy that needs to be achieved and that is acceptable to 
the business. A reference point exists in the ‘estimating trumpet’ but the reader should additionally research their 
own industry's expectations and apply the industry rules as necessary. 

m The many and varied factors that additionally affect estimating, such as the planning horizon, project duration, 
people, structure, padding and culture. 

m Understanding what is being estimated: 

— Resources: Estimation of human resources, plant, equipment, raw material/s, capital and other. 

— Time: Estimation of the duration of the individually committed resources that will be required plus an estimation 
of the overall durations of the work packages and tasks within the WBS. 

— Costs: The estimation of the cost of resources and any other identified costs that must be considered, to ensure 
a full and complete project budget can be proposed for approval. 

m Understanding the general estimating process, as illustrated in Figure 8.2, earlier in this chapter, not forgetting while 
the resources are a major source of items to estimate, there are also many other ancillary items that will need to be 
identified and estimated. 

m Understanding the general approaches to estimating including top-down (broad-range) estimates, bottom-up 
(detailed) estimates and the hybrid approach of phase or rolling-wave estimating, where detailed (bottom-up) 
estimates are achieved for immediate work, and work in the future is estimated at a higher level (top-down). 

m Understanding the large number of estimating tools and techniques available to the project manager. These include 
expertjudgement, analogous estimating, parametric estimating, three-point estimating, bottom-up estimating, 
data analysis, decision-making, meetings, alternatives analysis, reserve analysis, cost of quality (CoQ), and Project 
Management Information Systems. 

The level of effort that is gone into should follow the old saying of ‘no more than is necessary and sufficient’. It is well 
known that up-front efforts to clearly define project objectives, scope and specification vastly improve the accuracy of 
time, cost and resource estimates. 


https://ww w.pmi.org/learning/featur edtopics/proje ctestimating 





https://ww w.pmi.org/learning/library/commercially-available-costestimatingsoftware-systems-5457 
https://www.softwaread@vice.com/construction/cos testimating-software-comparison/ 
http://2020projectmanagement.com/2013/07/1 2-basicrulesfor-estimating-yourproject/ 


https://www.praxisframework.org/en/resource-pages/dooley thoughts-on-estimating 
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alternative analysis expert judgement reserve analysis 
analogous estimating function point estimating rolling-wave planning 
bottom-up estimates indirect costs (G&A or overhead costs) templates 
contingency lessons-learned three-month rule 
cost of quality (COQ) Padding estimates three-point estimate 
Delphi method Parametric estimating top-down estimates 
direct costs PERT method vendor bid analysis 
estimating trumpet phase estimating 

estimating tools range estimating 


Review questions 


uNa 


ne 


~ga 


Why are accurate estimates critical to effective project management? 
How does the culture of an organisation influence the quality of estimates? 


What are the differences between the bottom-up and top-down estimating approaches? Under what conditions would 
you use one over the other? 


What is your understanding of the wider definition of ‘resources’? 


The ‘estimating trumpet’ illustrates tolerances and expectations around levels of estimating accuracy across the life 
cycle. How do the tolerances resonate with your organisation’s expectations around estimating? 


Explain the difference between analogous and parametric estimating. 





What is the general sequence of events that typically occurs when estimating at the work package level? 


a 


Mrs Tolstoy and her husband, Serge, are planning their dream house. The lot for the house sits high on a hill with a 
beautiful view of the Blue Mountains. The plans show the size of the house to be 500 square metres. The average 
price for a lot and house similar to this one has been $700 per square metre. Fortunately, Serge is a retired plumber 
and feels he can save money by installing the plumbing himself. Mrs Tolstoy feels she can take care of the interior 
decorating. 


The following average cost information is available from a local bank that makes loans to local contractors and disperses 
progress payments to contractors when specific tasks are verified as complete. 


24% Excavation and framing complete 

8% Roof and fireplace complete 

3% Wiring roughed in 

6% Plumbing roughed in 

5% Siding on 

17% Windows, insulation, walls, plaster and garage complete 

9% Furnace installed 

4% Plumbing fixtures installed 

10% Exterior paint, light fixtures installed, finish hardware installed 
6% Carpet and trim installed 
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m 4% Interior decorating 
m 4% Floors laid and finishe 
(a) What is the estimated cost for the Tolstoy’s house if they use contractors to complete the entire house? 


(b) Estimate what the cost of the house would be if the Tolstoys use their skills to do some of the work themselves. 


2. You are about to embark on a project to introduce a Project Management Information System that integrates the 
functions of scheduling, risk management and social media (blogs, forums and wikis) and that must also allow 
contractors to log into the system to update work package performance status. How would the vendor bid analysis and 
expert judgement approaches be applied in this situation? What is the value in applying both techniques? What would 
be the downside of applying both techniques? 

3. Refer to one of your own recent projects and review the different estimating tools and techniques that have been 
outlined in this chapter. Make recommendations as to which of the tools and techniques might have worked best in your 
project. Also, identify the estimating techniques you chose and reflect on what led you to use these. Which tools might 
have worked better? What recommendations would you now make tothe business? 





Note: An appendix, relevant to this chapter entitled Learning Curves for Estimating is available online. See also 
the online resources Delphi Method, Sharp Printing AG and Function Points. 
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PROJECT SCHEDULE MANAGEMENT 





Learning elements 


Understand the basis of project schedule management and how to capture 
the dynamics of scheduling in the subsidiary plan known as the Schedule 
Management Plan. 


Understand the significance of building a realistic, accurate project schedule. 
Construct an activity-on-node (AON) network diagram and identify the critical path(s). 


Understand the relationship between activities and resources in a scheduling 
context. 


Understand the relationship between activities and costs in a scheduling context. 


Be able to identify and diagnose some of the more common issues in project 


scheduling. 
In this chapter 
9.1 Introduction 9.10 The resource scheduling problem 
9.2 Planning schedule development 9.11 Resource allocation methods 
9.3 Developing the project schedule 9.12 Splitting activities 
9.4 From work package to network 9.13 Benefits of scheduling resources 
9.5 Constructing a project network 9.14 Assigning project work 
9.6 Activity-on-node (AON) 9.15 Multi-project resource schedules 


TUTE Fs 9.16 Using the resource schedule to 


9.7 Extended network techniques to develop a project cost baseline 


come dees t reeliy 9.17 Scrum/Agile considerations 


9.8 Reducing project duration Summary 


9.9 Options for accelerating project 
completion 
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9.1 INTRODUCTION 


Project schedule management is probably one of the most complex areas of project management. 
Devising an elegant project schedule that represents all the work of the project in asequenced manner 
can provide many challenges. To support the development of project schedules, therefore, a number 
of tools and techniques have to be applied, including: 


@ further development of the work breakdown structure (WBS) 


@ estimating to a more accurate level the durations and resources required to accomplish the work 
packages 


@ developing and understanding project network diagrams 


@ developing and controlling the project schedule chart (often referred to as the Gantt chart) 


This chapter also discusses examples of often-used project management terminology that is 
associated with the development, tracking and reporting of the project schedule. 


9.2 PLANNING SCHEDULE DEVELOPMENT 


The Project Management Institute (PMI) introduced a plan process group to all of the knowledge areas to 
promote a consistent approach towards the planning of each knowledge area: that is, project managers 
plan the approach before actually doing it. Schedule management is no different in this respect, and 
as such, project managers plan project schedule management. The outcomes of the planning activities 
are typically captured ina subsidiary plan, referred to as the Schedule Management Plan. Before we 
examine the detail in how to craft and rationalise project network diagrams and project schedules, the 
PMI planning approach will be taken with the introduction of the Schedule Management Plan (previously 
known as the Time Management Plan). The contents of this planning document could include: 


E The schedule management approach: A description of the overarching strategy and approach 
towards the scheduling of the project. 


E Policy and procedures: Identifying any company policy and procedures that have to be adopted 
by the project in relation to schedule management. For example: 


— adoption of Microsoft® Project as the scheduling tool 


— milestone management, as documented in the organisation's guide to project and program schedule 
management. 


E Time estimation tools: Documenting the organisational tools that will be used within the project 
for the estimation of ‘time’ (durations and (or) start-end dates). These may include inhouse 
built tools that provide estimates based on the history of previous projects’ schedule, budget, 
resourcing and other data. 


E Schedule management and information systems: Detailing the project's information management 
systems that will be used within the project for the management of the project schedule and 
the production of earned value management (EVM) data. This would be supplemented with 
information on the projects roles and responsibilities in relation to schedule management. This 
could be captured within the projects RASCI Matrix (refer Chapter 14) for example. 


E Schedule/time reporting arrangements: Identifying within which project reports schedule-related 
information will be reported. Specify what information is reported on, where it is to come from in 
the project, when it is required by the business, and who is responsible for collating and updating 
this information in readiness for producing the project status report. 
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Æ Schedule control: This section of the Schedule Management Plan defines how the project's 
schedule will be controlled throughout the life of the project, including details about the 
frequency of updates and schedule reviews, as well as how communicating the schedule and 
progress made will take place. Governance also needs to be established, for example about: 


— when schedule baselines are to be established 


— control of these schedule baselines, to ensure any new baselines are issued and managed ina 
planned manner. This activity may be integrated with defining the project's change request process 
(as discussed in Chapter 7). 


E Schedule changes and thresholds: Establishing the use of the change request process for any 
schedulerelated changes that occur after the schedule baseline has been set. Also captured here 
are any threshold limits the project manager holds (as agreed by the steering committee), for 
example: ‘The project manager can approve changes <.05 day slippage to the critical path, but 
must also report these slippages to the steering committee’. 


= %complete rules: The project manager should agree and document how % complete’ is to be 
determined and document and then communicate these rules to the project team. For example, consider 
which of the below (or other) rules is to be applied by anyone leading the work on a work package: 


— 0/100 rule: This rule assumes credit is earned for having performed the work once it is completed. 
Hence, 100 per cent of the budget is earned when the work package is completed. This rule is used 
for work packages which have very short durations. 


— 50/50 rule: This approach allows 50 per cent of the value of the work package budget to be earned 
when it is started, and 5@ per cent to be earned when the package is completed. This rule is popular 
for work packages of a short duration and small total costs. 


— Interval rule: Some organisations use a fixed interval per cent-complete rule (rounding down to 
25%/50%/75% intervals ). The intervals can, however, take on any set of interval values, as defined 
by the organisation. (Note that intervals of ‘thirds’ is also popular.) 


— Per cent complete with weighted monitoring gates: This more recent rule uses subjective estimated 
‘per cent complete’ in combination with hard, tangible monitoring points. 


E Schedule management roles and responsibilities: This section should describe the roles and 
responsibilities in relation to the management of the schedule, who and how data is updated, 
verified and reported on (for example). 


E Assumptions and constraints: Consider what assumptions are being made in relation to the 
schedule factors for the project (remember an ‘assumption’ is an assumed statement of truth). 
Also, capture information about what schedule factors may constrain the project. For example, if 
access to a particular resource type is restricted, this will impact the schedule with the effect of 
extending the duration of assigned task. 


@ Risk review: Ensure that a risk review of any scheduling activities is carried out and that 
identified risks are entered into the risk register under the category of ‘schedule’. Either reflect 
those risks in this part of the Schedule Management Plan, or make reference to the Risk Register 
+ risk IDs of the risks raised. 


E Lessons-learned: Document lessons-learned from relevant previous projects (either internal or 
external to the organisation) regarding schedule management and state how this project will be 
designed to avoid or exploit these lesson(s). 


Source: @ 2018 Br Neil Pearson 
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9.3 DEVELOPING THE PROJECT SCHEDULE 


Once the governance around project scheduling has been carried out, the task of developing the project 
schedule can start. The project schedule is developed from the information generated in building the 
WBS and from developing the estimates of time and resources. It is a graphic visualisation of the work 
to be carried out. The network depicts project activities that must be completed, the logical sequences 
involved, and the interdependencies of the activities to be completed. In most cases, it also depicts 
the timepoint for activities to start and finish, along with details of the longest path(s) through the 
network, but the shortest time the project can be completed in (this is referred to as the critical path). 
The project network is the framework that is used for the project information system that will be 
used by the project manager to track the project and to make decisions concerning project time, cost 
and performance (scope). 

Developing the project network takes time, and therefore, it costs money. Are networks really 
worth the struggle then? The answer is a resounding ‘Yes!’ The network is easily understood by 
others because the network presents a graphic display of the flow and sequence of work through 
the project. Once the network is developed, it can very easily be modified or changed when 
unexpected events occur as the project progresses (e.g. to model changes to the project). For 
example, if materials for a task are delayed, the impact can be quickly assessed and the whole 
project revised in only a few minutes with an appropriate software package (such as Microsoft 
Project). These revisions can subsequently be communicated to all project participants quickly 
and efficiently. 

The project network also provides other invaluable information and insights: it provides the basis 
for scheduling resources and tracking costs and it enhances communication that. ‘melds’ all managers 
and groups together in meeting the time, cost and performance (scope) objectives of the project. It 
provides a calculated estimate of the project's duration, rather than picking a project completion date 
from a hat or merely applying someone's ‘preferred’ date. The network provides times when activities 
can start and finish, and when they can be delayed. It provides the basis for budgeting the cash flow of 
the project. It identifies which activities are ‘critical’ and therefore which should not be delayed if the 
project is to be completed as planned. It highlights which activities to consider if the project needs to 
be compressed to meet a deadline. 

There are other reasons project networks are worth their weight in gold. Basically, project 
networks minimise surprises by getting the schedule out early; thereby allowing corrective feedback 
to take place. It's no wonder that practitioners commonly claim that that the project network 
represents three-quarters of the planning process. Perhaps this is an exaggeration, but nonetheless it 
signals the perceived importance of the project network as a guidance tool that can support project 
managers working in the field. Although this is one of the more complex knowledge areas of project 
management, time invested in becoming familiar with these tools and techniques not only provides 
benefits for planning the current project, but also can facilitate diagnosis and re-planning when things 
do not go as planned. The project schedule (network) is usually a key project artefact that is developed 
during the Planning stage of the project. 


9.4 FROM WORK PACKAGE TO NETWORK 


Project networks are developed from the WBS. The project network is a visual flow of the sequence, 
interrelationships and dependencies of all the activities that must be accomplished to complete the 
project. An activity is an element in the project that consumes time—for example, work or waiting. 
Work packages from the WBS are used to build the activities found in the project network. An activity 
can include one or more work packages. The activities are placed in a sequence that provides for 
orderly completion of the project. Networks are built using nodes (boxes) and arrows (lines). The 
node depicts an activity, and the arrow shows dependency and general project flow. 
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Integrating the work packages and the network represents a point where the management process 
often fails, in practice. The primary explanations for failure are that (1) different. groups (people) are 
used to define work packages and activities and (2) the WBS is poorly constructed and is not deliverable/ 
outputoriented. Integration of the WBS and project network is crucial to effective project management 
and control of the project. The project manager must be careful to guarantee continuity by having 
some of the same people who defined the WBS and work packages also develop the project network. 

Networks provide the project schedule by identifying dependencies, sequencing and timing of 
activities, which the WBS is not designed to do. The primary inputs for developing a project network 
are the work packages. Remember, a work package is defined independently of other work packages, 
has definite start and finish points, requires specific resources, includes technical specifications, and 
has cost estimates for the package. However, the dependency, sequencing and timing (e.g. where the 
work package actually takes place in relation to the timeline of the project) of each of these factors is 
not included in the work package. A network activity can include one or more work packages. 

Figure 9.1 shows a segment of a WBS. The lowest level deliverable in Figure 9.1 is ‘circuit board’. 
The cost accounts (design, production, test, software) denote project work, the organisational unit 
responsible and time-phased budgets for the work packages. Each cost account represents one or 
more work packages. For example, the design cost account has two work packages (D-1-1 and D-1-2), 
specifications, and documentation. The software and production accounts also have two work packages. 
Developing a network requires sequencing tasks from all work packages that have measurable work. 

Figure 9.1 traces how work packages are used to develop a project network. You can trace the 
usage through the coding scheme. For example, Activity A uses work packages D-I-1 and D-1-2 
(specifications and documentation), while Activity C uses work package S-22-1. This methodology (of 
selecting work packages to describe activities) is used to develop the project network, which sequences 
and times project activities. Care must be taken to include all work packages. The project manager 
derives activity time estimates from the task times in the work package. For example, Activity B 
(proto 1) requires five weeks to complete and Activity K (test) requires three weeks to complete. 


9.5 CONSTRUCTING A PROJECT NETWORK 


There are two approaches to constructing a project network. Before one can be chosen over the other, 
it is important to understand the terminology used in scheduling. 


9.5.1 Terminology 


Every professional field has its jargon that colleagues can use to communicate comfortably and 
expediently with each other. The field of project management is no different in this regard and the 
following list illustrates some of the jargon that may be heard when project networks are being built: 


m Activity: For project managers, an ‘activity’ is an element of the project that requires time. 
Typically, an activity consumes time—either while people work, or while people wait. Examples 
of the latter are time spent waiting for contracts to be signed, time taken for materials to arrive, 
time for construction approvals from the government to come through, the length of time until 
budget clearance, etc. Activities usually represent one or more tasks from a work package. 
Descriptions of activities should use a verb-noun format, for example, ‘develop product 
specifications’. As noted previously, an activity in a network sense could include the work of 
multiple work packages. 

m Merge activity: This is an activity that has more than one activity immediately preceding it (i.e. 


more than one dependency arrow flowing to it). 


E ParalleVsequence activities: These are activities that can take place at the same time, if the 
project manager wishes. However, the project manager may choose to have parallel activities not 
occur simultaneously—that is, they occur in sequence. 
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Figure 9.1 V 





Lowest Circuit 
element board 


Design Design 
cost WP D-1-1 Specifications 
account WP D-1-2 Documentation 





Production Production 
cost WP P-10-1 Proto 1 
account WP P-10-2 Final Proto 2 








Test Test systems 
cost WP T-13-1 Test 
account 





2) Gl Ses an emer ne) eS 10) 





Software Software 
cost WP S-22-1 Software preliminary 
account WP S-22-2 Software final version 





Heo-ase 





Activity network for circuit board work packages 












Specifications Final 
and documentation software 3 
2 


Software 


preliminary 
3 


E Path: A sequence of connected, dependent activities. 


m Critical path (CP): When this term is used, it means the path(s) with the longest duration 
through the network, but which represents the [current] shortest time to complete the 
project. If an activity on the path is delayed, the project is delayed by the same amount 
of time (unless efficiencies in the project network can be made—such as crashing and 
fast-tracking). 


= Burst activity: This activity has more than one activity immediately following it. (i.e. more than 
one dependency arrow flowing from it). 
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9.5.2 Two approaches 


The two approaches used to develop project networks are known as activity-on-node (AON) 
and activity-on-arrow (AOA). Each method uses a building block—an arrow or a node. 
Their names derive from the fact that the former uses a node to depict an activity, while the 
latter uses an arrow to depict an activity. Since their first iteration (in the late 195@s) many 
practitioners have offered enhancements to these two models. Despite this, the basic models 
have withstood the test of time and still prevail with only minor variations in form. In practice, 
the AON method has come to dominate most projects. Hence, this text will deal primarily with 
AON. However, the chapter also includes an online appendix demonstrating AOA methods (see 
Appendix 9.1) for people whose organisation uses the AOA approach. There are good reasons 
for project management students to be proficient in both methods: different departments and 
organisations will have their favourite approach and will frequently be loyal to software that is 
already purchased and being used. 





New employees or outsiders are seldom in a position to govern the choice of method used. If 
subcontractors are used, it is unreasonable to ask them to change their whole project management. 
system to conform to the approach you are using. The point is, a project manager should feel 
comfortable moving among projects that use either AON or AOA. 


9.5.3 Basic rules to follow in developing project networks 


The following eight rules apply (in general) when developing a project network: 


1. Networks flow typically from left to right. 

2. An activity cannot begin until all preceding connected activities have been completed. 

3. Arrows on networks indicate precedence and flow. Arrows can cross over each other. 

4. Each activity should have a unique identification number (often the WBS item number). 

5. An activity identification number must be larger than that of any activities that precede it. 

6. Looping is not allowed (in other words, recycling through a set of activities cannot take place). 


Conditional statements are not allowed (that is, this type of statement should not appear: ‘Tf 
successful, do something; if not, do nothing’). 


8. Experience suggests that when there are multiple starts, a common start node can be used to 
indicate a clear project beginning on the network. Similarly, a single project end node can be used 
to indicate a clear ending. 


Read Snapshot from Practice: The ‘yellow sticky’ approach to see how these rules are used to 
create project networks. 


9.6 ACTIVITY-ON-NODE (AON) FUNDAMENTALS 


The activity-onnode (AON) method is sometimes referred to as the ‘precedence diagram method’. 
Figure 9.2 shows a few typical uses of building blocks for the AON network construction. An activity is 
represented by a node (box). The node can take many forms, but in recent years it has predominantly 
been represented as a rectangle (box). The dependencies among activities are depicted by arrows 
between the rectangles (boxes) on the AON network. The arrows indicate how the activities are 
related and the sequence in which things must be accomplished. The length and slope of the arrow 
are arbitrary and set for convenience of drawing the network. The letters in the boxes serve here to 
identify the activities, to help students learn the fundamentals of network construction and analysis. 
In practice, activities have identification numbers and descriptions. 
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Three basic relationships must be established for activities included in a project network. The 
relationships can be found by answering the following three questions for each activity: 


1. Which activities must be completed immediately before this activity? These activities are called 
predecessor activities. 


2. Which activities must immediately follow this activity? These activities are called successor 
activities. 

3. Which activities can occur while this activity is taking place? This is known as a concurrent or 
parallel relationship. 


Sometimes a project manager can use only questions 1 and 3 to establish relationships. This 
information allows the network analyst to construct a graphic flow chart of the sequence and logical 
interdependencies of project activities. 

Figure 9.2A is analogous to a list of things to do where you complete the task at the top of the list 
first and then move to the second task, and so on. This figure tells the project manager that Activity 
A must be completed before Activity B can begin, and Activity B must be completed before Activity C 


can begin. 


Figure 9.2 i e ne < fundamentals 
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Figure 9.2B tells us that. Activities Y and Z cannot begin until activity X is completed. This 
figure also indicates that. Activities Y and Z can occur concurrently or simultaneously if the project 
manager wishes; however, it is not a necessary condition. For example, pouring a concrete driveway 
(Activity Y) can take place while landscape planting (Activity Z) is being accomplished, but land 
clearing (Activity X) must be completed before Activities Y and Z can start. Activities Y and Z are 
considered parallel activities. Parallel paths allow concurrent effort, which may shorten the time 
to do a series of activities. Activity X is sometimes referred to as a burst activity because more than 
one arrow ‘bursts’ from the node. The number of arrows indicates how many activities immediately 
follow Activity X. 

Figure 9.2C shows that Activities J, K and L can occur simultaneously if desired, and Activity M 
cannot begin until Activities J, K and L are completed. Activities J, K and L are parallel activities. 
Activity M is called a ‘merge’ activity because more than one activity must be completed before M can 
begin. Activity M could also be called a milestone—a significant accomplishment. 

In Figure 9.2D, Activities X and Y are parallel activities that can 
take place at the same time; Activities Z and AA are also parallel Table 9.4 Network information 
activities. But Activities Z and AA cannot begin until Activities X and Y 
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Figure 9.3 shows the first steps in constructing the AON project 


Figure 9.3 Koll Business Center (USA)— 


network from the information provided in Table 9.1. We see that partial network 





Activity A (application approval) has nothing preceding it; therefore, 
it is the first node to be drawn. Next, we note that Activities B, C and D 





(construction plans, traffic study and service availability check) are 






KOLL BUSINESS CENTER 


all preceded by Activity A. We draw three arrows and connect them 
County Engineers Design Department 


to Activities B, C and D. This segment shows the project manager that 
Activity A must be completed before Activities B, C and D can begin. 
After A is completed, B, C and D can go on concurrently, if desired. 

Figure 9.4 shows the completed network with all activities and 
precedences depicted. 


Construction 
At this point, our project network presents us with a graphic ‘map’ plans 
of the project activities with sequences and dependencies shown. This 
information is tremendously valuable to those managing the project. 
However, estimating the duration of each activity will further increase Traffic 
the value of the network (refer to Chapter 10). Arealistic project schedule study 
requires reliable time estimates for project activities. The addition of 
time to the network allows us to estimate how long the project will 


take. Assigning time also allows us to estimate when activities can or 


must start, when resources must be available, which activities can be aoe bility 
delayed and when the project is estimated to be completed. Deriving an check 


activity time estimate necessitates the early assessment of resource 
needs in terms of materials, equipment and people. 
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9.6.1 The process of building the activity-on-node network 


Drawing the project network places activities in the right sequence for calculating their start and 
finish times. Activity time estimates are taken from the task times stated in the work package and are 
added to the network (review Figure 9.2). 

Performing a few simple computations allows the project manager to complete a process known as 
the ‘forward and backward pass’. Completion of the ‘forward and backward pass’ will help to answer 
the following questions: 


FORWARD PASS: EARLIEST TIMES 
1. How soon can the activity start? (Early start or ES) 
2. How soon can the activity finish? (Early finish or EF) 


3. How soon can the project be finished? (Expected time or TE) 


BACKWARD PASS: LATEST TIMES 
1. How late can the activity start? (Late start or LS) 
2. How late can the activity finish? (Late finish or LF) 


3. Which activities represent the critical path (CP)? This is the longest path in the network and the 
shortest time in which the activity can be completed, which, if delayed, will delay the project. 


4. How long can the activity be delayed? (Slack or float, SL) 


The forward and backward pass processes are described next. 


FORWARD PASS: EARLIEST TIMES 


The forward pass starts with the first project activity (activities) and traces each path (chain of 
sequential activities) through the network to the last project activity (activities). As you trace along 


a project network) 
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SNAPSHOT FROM PRACTICE The ‘yellow sticky’ approach (for constructing 





In practice, small project networks (25 to 100 activities) 
are frequently developed using yellow Post-it” note 
stickers. The meeting requirements and the process for 
the project team to follow are described below: 


1. There should be a meeting facilitator and (of course) 
the project team members present at the meeting. 

2. One yellow sticker {7 x 10 centimetres or larger) will 
be needed for each activity, and the description of the 
activity should be printed on the sticker. 

3. An erasable whiteboard (a long, approximately 
1 metre-wide piece of butcher's paper can be used 
in place of the whiteboard if none is available) ane a 
marker pen. 


All of the yellow stickers are placed within easy view of 
all of the team members. The team begins by identifying 
activities (activity stickers) that have no predecessors. Each 
of these activity stickers is then attached to the whiteboard 
(or butcher’s paper, if used). A start node is drawn, and a 
dependency arrow is connected to each activity. 


Given the initial network start activities, each 
activity is next examined for any immediate successor 
activities. These activities are attached to the whiteboard 
and dependency arrows drawn. This process is 
continued until all of the yellow stickers are attached 
to the whiteboard with dependency arrows. (Note: The 
process can be reversed, beginning with those activities 
that have no successor activities and connecting them 
to a project end node. The predecessor activities are 
selected for each activity ane attached to the whiteboard 
with dependency arrows marked.) 

When the process is complete, the dependencies 
are recorded using the project software that 
develops a computer-designed network, along with 
the critical path(s) and early, fate and slack times. This 
methodology sensitises team members early on to the 
interdependencies between activities of the project. 
This methodology also empowers team members by 
allowing them input into the important decisions they 
must implement later. 


the path, you add the activity times. The longest path denotes the overall project completion time for 
the plan and is called the critical path (CP). Table 9.2 lists the activity times, in workdays, for the Koll 
Business Center example we used for drawing a network. 

Figure 9.5 shows the network with the activity time estimate found in the node (see ‘DUR’ for 
duration in the legend). For example, Activity A has a duration of five workdays and Activity G has 
a duration of 17@ workdays. The forward pass begins with the project start time, which is usually 
‘time zero’. (Note: Calendar times can be calculated for the project later in the chapter when the 
network diagram is transferred into a software package as a Gantt chart for the purpose of project 
control.) 

In our Koll Business Center example, the early start time for the first activity (Activity A) is zero. 
This time is found in the upper left corner of the Activity A node in Figure 9.6. 

The early finish for Activity Ais 5 (ES + DUR = EF or 0 + 5 = 5). Next, we see that Activity A is the 
predecessor for Activities B, C and D. Therefore, the earliest these activities can begin is the instant 
in time when Activity A is completed; this time is five workdays. You can now see in Figure 9.6 that 
Activities B, C and D can all start the moment Activity A is complete and, therefore, have an early 
start (ES) of 5. Using the formula ES + DUR = EF, the early finish (EF) times for Activities B, C and D 
are 20, 15 and 10. What is the ES for Activity E, which is a merge activity? Is it 15 or 20? The answer 
is 20 because all activities immediately preceding Activity E (B and C) must be completed before 
Activity E can begin. Because Activity B will take the longest to complete, it controls the ES of 
Activity E. The same process is used for determining the ES for Activity F. It is preceded by Activities 
B, C and D. The controlling early finish (EF) time is Activity B, which has the longer early finish 
(20 versus 15 and 10) of the immediate predecessors (Activities B, C and D) of Activity F. Stated 
differently, the forward pass assumes every activity will start the instant the last of its predecessors 
is finished. 
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Table 9.2 Network information 


Koll Business Center County Engineers Design Department 





A Application approval None 5 

B Construction plans A 15 

C Traffic study A 10 

D Service availability check A 5 

E Staff report B,C 15 

E Commission approval B,C, D 10 

G Wait for construction F 170 

H Occupancy EG 35 

The forward pass requires that you remember just three things when calculating early activity 

times: 


1. You add activity times along each path in the network (ES + DUR = EF). 


to 


You carry the early finish (EF) to the next activity where it becomes its early start (ES), unless... 


3. The next succeeding activity is a merge activity. In this case you select the largest early finish 
number (EF) of all its immediate predecessor activities. 


In our example in Figure 9.6, the EF for Activity F (3@) is carried to Activity G, where it becomes 
its ES (80). We see Activity H is a merge activity and therefore find the largest EF of its immediate 
predecessors (Activities E and G). In this case, the choice is between the EF times of 35 and 200; the 
choice for the ES of Activity H is 200. The EF for Activity H (285) becomes the earliest the project 
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can be expected to be completed (TE) under normal conditions. The three questions derived from the 
forward pass have been answered; that is, early start (ES), early finish (EF) and the project duration 
(TE) times have been calculated. 

Next, we'll take a look at the backward pass. 


BACKWARD PASS: LATEST TIMES 


The backward pass starts with the last project activity (activities) on the network. You trace 
backwards on each path, subtracting activity times, to find the late start (LS) and finish times (LF) for 
each activity. Before the backward pass can be calculated, the late finish for the last project activity 
(activities) must be selected. In early planning stages, this time is usually set equal to the early finish 
(EF) of the last project activity (or in the case of multiple finish activities, the activity with the largest 
EF). In some cases an imposed project duration deadline exists, and this date will be used. Let us 
assume for planning purposes we can accept the EF project duration (TE) equal to 235 workdays. The 
LF for Activity H becomes 235 workdays (EF = LF) (see Figure 9.7). 
The backward pass is similar to the forward pass; you need to remember three things: 


1. You subtract activity times along each path, starting with the project end activity 
(LF — DUR = LS). 
2. You carry the LS to the next preceding activity to establish its LF, unless. . . 
3. The next preceding activity is a burst activity; in this case, you select the smallest LS of all its 


immediate successor activities to establish its LF. 


Let’s apply these rules to our Koll Business Center example. Beginning with Activity H (occupancy) 
and an LF of 235 workdays, the LS for Activity H is 200 workdays (LF — DUR = LS or 235 — 35 = 200). 
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Figure 9.7 AON network backward p 
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The LS for Activity H becomes the LF for Activities E and G. The LS for Activities E and G becomes 185 
(200 — 15 = 185) and 30 workdays (200 — 170 = 38), respectively. Next, the LS for Activity G becomes the 
LF for Activity F, and its LS becomes 28. At this point we see that Activities B and C are burst activities 
that tie to Activities E and F. The late finish for Activity B is controlled by the LS of Activities E and 
F. The LS for Activity E is 185 days, and for Activity F, 2@ days. Follow the arrows backward from 
Activities E and F to Activity B. Note that LS times for Activities E and F have been placed to the right 
of the node so you can select the smallest time—2@ days. The latest. Activity B can finish is 2@ days, or 
Activity F will be delayed and so will the project. The LF for Activity C is identical to Activity B because 
it is also controlled by the LS of Activities E and F. Activity D simply picks up its LF from Activity F. By 
calculating the LS (LF — DUR = LS) for Activities B, C and D, we can determine the LF for Activity A, 
which is a burst activity. You see that the finish of Activity A is controlled by Activity B, which has the 
smallest LS of Activities B, C and D. Because the LS for Activity B is time period 5, the LF for Activity A is 
5, and its LS is time period zero. The backward pass is complete, and the latest activity times are known. 


DETERMINING SLACK (OR FLOAT) 


When the forward and backward passes have been calculated, it is possible to determine which 
activities can be delayed, by calculating the ‘slack’ or ‘float’. Total slack tells us the amount of time an 
activity can be delayed without delaying the project. Stated differently, totel slack is the amount of 
time an activity can exceed its early finish date without affecting the project end date or an imposed 
completion date. 

Total slack (SL) or float for an activity is simply the difference between the LS and ES (LS — ES 
= SL) or between LF and EF (LF — EF = SL). For example, in Figure 9.8 the slack for Activity C is five 
days, for Activity D 1 days and for Activity G zero. If the slack of one activity in a path is used, the 
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ES for all activities that follow in the chain will be delayed and their slack reduced. Use of total slack 
must be coordinated with all participants in the activities that follow in the chain. 

After slack for each activity is calculated, the critical path(s) is (are) easily identified. When the LF 
= EF for the end project activity, the critical path can be identified as those activities that also have LF 
= EF or a slack of zero (LF — EF = @ or LS — ES = @). The critical path is the network path(s) that has 
(have) the least slack in common. 

This awkward arrangement of words is necessary because a problem arises when the project 
finish activity has an LF that differs from the EF found in the forward pass—for example, an imposed 
duration date. If this is the case, the slack on the critical path will not be zero; it will be the difference 
between the project EF and the imposed LF of the last project activity. For example, if the EF for the 
project is 235 days, but the imposed LF or target date is set at 220 days, all activities on the critical path 
would have a slack of minus 15 days. Of course, this would result in a late start of minus 15 days for 
the first project activity—a good trick if the project is to start now. Negative slack occurs in practice 
when the critical path is delayed. 

In Figure 9.8, the critical path is marked with dashed arrows and nodes—Aactivities A, B, F, G and 
H. Delay of any of these activities will delay the total project by the same number of days. Critical 
activities typically represent. about 1@ per cent of the activities of the project. Therefore, project 
managers pay close attention to the critical path activities to be sure they are not delayed. See 
Snapshot from Practice: The critical path. 

We use the term sensitivity to reflect the probability the original critical path(s) will change 
once the project is initiated. Sensitivity is a function of the number of critical or near-critical paths. 
A network schedule that has only one critical path and non-critical activities that enjoy significant 
slack would be labelled insensitive. Conversely, a sensitive network would be one or more than 
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SNAPSHOT FROM PRACTICE The critical path 





The critical path method (CPM) has long been considered who are doing the work and by reading the facial 
the ‘Holy Grail’ of project management. The following expressions of people—much more than | can gain 
comments were made by highly experienced project from a number-driven status report’ 


managers when asked about the significance of the 


“Ae 4 D ; m ‘When | get calls from other managers asking to 
critical path in managing projects: 


“borrow” people or equipment, l'm much more 


m ‘| try to make it a point whenever possible to put my generous when it involves resources working on 
best people on critical activities or on those activities non-critical activities. For example, if another project 
that stand the greatest chance of becoming critical.’ manager needs an electrical engineer who is 


assigned to a task with five days of slack, l'm willing 
to share that engineer with another project manager 
for two to three days.’ 


m ‘| pay extra attention when doing risk assessment to 
identifying those risks that can impact the critical path 
(either directly or indirectly) by making a non-critical 


activity so late that it becomes critical. When I've got m ‘The most obvious reason the critical path is 
money to spend to reduce risks, it usually gets spent important is because these are the activities that 
on critical tasks.’ impact completion time. If | suddenly get a call from 


“above” saying they need my project done two 
weeks earlier than planned, the critical path is where 
I schedule the overtime and add extra resources to 
get the project done more quickly. In the same way, 
if the project schedule begins to slip, it's the critical 
activities | focus on to get back on schedule.’ 


m ‘| don't have time to monitor all the activities on a big 
project, but | make it a point to keep in touch with the 
people who are working on critical activities. When | 
have the time, they are the ones | visit to find out first- 
hand how things are going. It’s amazing how much 
more | can find out from talking to the “rank and file” 





critical paths and/or noncritical activities with very little slack. Under these circumstances, the 
original critical path is much more likely to change once work gets under way on the project. 

How sensitive is the Koll Business Center schedule? Not very, since there is only one critical path 
and each of the three noncritical activities have significant slack when compared to the estimated 
duration. 

Project managers assess the sensitivity of their network schedules to determine how much 
attention they should devote to managing the critical path. 


FREE SLACK (FLOAT) 


Free slack (FS) is unique. It is the amount of time an activity can be delayed without delaying any 
immediately following (successor) activity, or it is the amount of time an activity can exceed its early 
finish date without affecting the early start date of any successor(s). Free slack can never be negative. 
Only activities that occur at the end of a chain of activities, where you have a merge activity, can have free 
slack. Since the Koll Business Center project does not work well to demonstrate free slack, see Figure 9.9. 

In Figure 9.9, Activity 6 has free slack of 15, while Activities 2 and 3 do not. In this case, Activity 6 
is the last activity in the upper path, and it merges to Activity 7. Hence, to delay Activity 6 up to 15 
time units does not delay any following activities and requires no coordination with managers of 
other activities. Conversely, if either Activity 2 or 3 is delayed, the managers of following activities 
need to be notified that the slack has been used so they can adjust their start schedules. For example, 
if Activity 2 is delayed five time units, the Activity 2 manager should notify those in charge of the 
following activities (8 and 6) their slack has been reduced to 10 time units. Free slack for Activity 6 is 
also reduced to 10 units. 

Free slack occurs at the last activity in a chain of activities. In many situations, the ‘chain’ can have 
only one link. Activity 4 in Figure 9.9 is an example. It has free slack of 18 time units. Note that it needs 
no coordination with other activities—unless a delay exceeds the slack of 18 time units. 
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Figure 9.9 F 
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FS = free slack 


For a more typical example, imagine a chain of 2@ activities. Except for the last activity in the 
chain, delaying any of the other 19 activities will necessitate notifying the managers of the remaining 
activities in the chain that you will be late. Again, note that total slack is for the whole path. Thus, 
if all the slack is used on the second activity in the 20-activity chain, the remaining activities in the 
chain will have zero slack. The slack is not available for use by the other managers affected; it is 
gone! 


9.6.2 Using the forward and backward pass information 


Returning to the Koll Business Center project network in Figure 9.8, what does a slack of 10 workdays 
for Activity D (Service check) mean for the project manager? In this specific case it means Activity 
D can be delayed 1@ days. In a larger sense, the project manager soon learns that ‘slack’ is important 
because it allows flexibility in scheduling scarce project resources—personnel and equipment—that 
are used on more than one parallel activity or another project. 

Knowing the four activity times of ES, LS, EF and LF is invaluable for the Planning, Executing, 
and Monitoring and Controlling stages of the project. The ES and LF tell the project manager the time 
interval in which the activity should be completed. For example, Activity E (Staff report) must be 
completed within the time interval 20 and 20@ workdays; the activity can start as early as day 2@ or 
finish as late as day 2@@. Conversely, Activity F (Commission approval) must start on day 2@ or the 
project will be delayed. 

When the critical path is known, it is possible to tightly manage the resources of the activities on 
the critical path so no mistakes are made that will result in delays. In addition, if for some reason 
the project must be expedited to meet an earlier date, it is possible to select those activities, or 
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combination of activities, that will cost the least to shorten the project. Similarly, if the critical path 
is delayed and the time must be made up by shortening some activity or activities on the critical path 
to make up any negative slack, it is possible to identify the activities on the critical path that cost the 
least to shorten. If there are other paths with very little slack, it may be necessary to also shorten 
activities on those paths. 

Ona practical note, the authors have worked on projects in an office environment where a large flag 
has been placed on the desks of those working on critical path activities. The unspoken ground rules 
for these people were: do not disturb unless absolutely necessary, and when help is requested, please 
assist. Ina geographically dispersed team, instant messaging (such as Skype) can be used with a virtual 
flag set against the names of people working on the critical path activities. Remember, communication 
is a key part of the project manager's role, and techniques such as these assist in communicating to 
others in the project team the significance of being allocated to a critical path activity. 


9.6.3 Level of detail for activities 


Timephasing the work and budgets of the project requires careful definition of the activities that make 
up the project network. Typically, an activity represents one or more tasks from a work package. How 
many tasks you include in each activity sets the level of detail. In some cases it is possible to end up 
with too much information to manage, and this can result in increased overhead costs. Managers of 
small projects can minimise the level of detail by eliminating some of the preliminary steps to drawing 
networks. Most larger firms also recognise the cost of ‘information-overload’ and work to cut down 
the level of detail in networks (and in most other dimensions of the project). 


9.6.4 Practical considerations 
NETWORK LOGIC ERRORS 


Project network techniques have certain logic rules that must be followed. One rule is that. conditional 
statements—such as ‘if test is successful, build proto [prototype]; if failure, redesign’—are not 
permitted. The network is not a decision tree; it is a project plan that we assume will materialise. 
If conditional statements were allowed, the forward and backward pass would make little sense. 
Although in reality a plan seldom materialises as we expect in every detail, it is a reasonable initial 
assumption. You shall see that once a network plan is developed, it is an easy step to make revisions 
to accommodate changes. 

Another rule that. defeats the project network and computation process is looping. Looping is an 
attempt by the planner to retum to an earlier activity. Recall that the activity identification numbers 
should always be higher for the activities following an activity in question, this rule helps to avoid the 
illogical precedence relationships among the activities. An activity should only occur once. If it is to 
occur again, the activity should have a new name and identification number and should be placed in the 
right sequence on the network. Figure 9.1@ shows an illogical loop. If this loop were allowed to occur, this 
path would perpetually repeat itself. Many software packages catch this type of logic error. 


ACTIVITY NUMBERING 


Figure 940 Illogical loop Each activity needs a unique identification code—usually a number. In practice, very 
elegant schemes exist. Most schemes number activities in ascending order; that is, each 


succeeding activity has a larger number so the flow of the project activities is towards 
> [e | project completion. It is customary to leave gaps between numbers (e.g. 1, 5, 10, 15). 


Gaps are desirable so you can add missing or new activities later. Because it is nearly 
impossible to draw a project network perfectly, numbering networks is frequently not 
done until after the network is complete. 

In practice, you will find software programs that accept numeric, alphabetic or a 
combination of activity designations. Combination designations are often used to identify 
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cost, work skill, departments and locations. As a general rule, activity numbering systems should be 
ascending and as simple as possible. The intent is to make it as easy as you can for project participants 
to follow work through the network and locate specific activities. 


USE OF SOFTWARE TOOLS TO DEVELOP PROJECT NETWORKS (OR SCHEDULES) 


All of the tools and techniques discussed in this chapter can be used with contemporary software 
packages. Two examples are shown in Figures 9.11 and 9.12. Figure 9.11 presents a generic AON 
computer output for an air control project. The critical path is identified by the unshaded nodes 
(Activities 1, 4, 6, 7 and 8). The activity description is shown on the top line of the activity node. The 
activity identification and duration are found on the right side of the node. The early start and early 
finish are on the left side of the node. The project starts on 1 January and is planned to finish 14 
February. 

Figure 9.12 presents an early start Gantt chart. Gantt charts are popular because they present an 
easy-to-understand, clear picture on a time-scaled horizon. They are used during planning, resource 
scheduling and status reporting. The format is a two-dimensional representation of the project 
schedule, with activities appearing down the rows and time appearing across the horizontal axis. In 
this computer output, the shaded bars represent the activity durations. The extended lines from the 
bars represent slack. For example, ‘software development’ has a duration of 18 days (shaded area of 
the bar) and 2@ days of slack (represented by the extended line). The bar also indicates the activity 
has an early start of 3 January, would end 2@ January, but can finish as late as 9 February because 
it has 2@ days of slack. When calendar dates are used on the time axis, Gantt charts provide a clear 
overview of the project schedule and therefore they are often seen posted on the walls of project 
offices. Unfortunately, when projects have many dependency relationships, the dependency lines 
soon become overwhelming and defeat the simplicity of the Gantt chart. 

Project management software can be a tremendous help in the hands of those who understand 
and are familiar with the tools and techniques discussed in this text. However, there is nothing more 
dangerous than someone using the software with little or no knowledge of how the software derives 
its output! Mistakes in input are very common and therefore it is essential to have someone in place 
who is skilled in the concepts, tools and information system, who will recognise when errors exist and 
rectify them to avoid false actions. 


CALENDAR DATES 


Ultimately, you will want to assign calendar dates to your project activities. If a software package is 
not used, dates are assigned manually. Lay out.a calendar of workdays (exclude non-workdays) and 
number them. Then relate the calendar workdays to the workdays on your project network. Most 
software packages will assign calendar dates automatically after you identify start dates, time units, 
non-workdays and other information based on the sequence of activities. 


MULTIPLE STARTS AND MULTIPLE PROJECTS 


Some software packages require a common start and finish event in the form of a node—usually a 
circle or rectangle—for a project network. Even if this is not a requirement, it is a good idea because 
it avoids dangler paths. Dangler paths give the impression that the project does not have a clear 
beginning or ending. If a project has more than one activity that can begin when the project is to start, 
each path is a dangler path. The same is true if a project network ends with more than one activity; 
these unconnected paths are also called danglers. Danglers can be avoided by tying dangler activities 
to a common project start or finish node. 

When several projects are tied together in an organisation, using a common ‘start’ and ‘end’ node 
helps to identify the total planning period of all projects. Use of pseudo or ‘dummy’ wait activities 
from the common start node allows different start dates for each project. 


Figure 9.11 Air control project: network diagram 
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Figure 9.12 Air control project: Gantt chart 


1st half 
Duration | Task name Start Finish Late start Late finish | Free slack | Total slack n223) 2130| 1/6 
2days Order review Tue 1/1 Wed 1/2 Tue 1/1 Wed 1/2 0 days 

15 days Order vendor parts Thu 1/3 Thu 1/17 Wed 1/16 Wed 1/30 13 days _— 
10 days Produce other standard parts Thu 1/3 Sat 1/12 Mon 1/21 Wed 1/30 18 days iH 
13 days Design custom parts Thu 1/3 Tue 1/15 Thu 1/3 Tue 1/15 O days pi 

18 days Software development Thu 1/3 Sun 1/20 Wed 1/23 Sat 2/9 20 days 
15 days Manufacture custom hardware Wed 1/16 Wed 1/30 Wed 1/16 Wed 1/30 0 days 


10days Assemble Thu 1/31 Sat 2/9 Thu 1/31 Sat 2/9 O days 
5days Test Sun 2/10 Thu 2/14 Sun 2/10 Thu 2/14 O days 
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9.7 EXTENDED NETWORK TECHNIQUES TO COME 
CLOSER TO REALITY 


The method for showing relationships among activities in the last section is called the finish-to-start 
relationship because it assumes all immediate preceding connected activities must be completed 
before the next activity can begin. In an effort to come closer to the realities of projects, some useful 
extensions have been added over time. The use of laddering was the first obvious extension that 
practitioners found very useful. 


9.7.1 Laddering 


The assumption that all immediate preceding activities must be 100 per cent complete is too restrictive 
for some situations found in practice. This restriction occurs most frequently when one activity 
overlaps the start of another and has a long duration. Under the standard finish-to-start relationship, 
when an activity has a long duration and will delay the start of an activity immediately following it, 
the activity can be broken into segments and the network drawn using a ‘laddering’ approach so the 
following activity can begin sooner and not delay the work. This segmenting of the larger activity 
gives the appearance of steps on a ladder on the network, thus the name. The classic example used 
in many texts and articles is ‘laying pipe’ because it is easy to visualise. The trench must be dug, the 
pipe laid, and the trench refilled. If the pipeline is one kilometre long, it is not necessary to dig one 
kilometre of trench before pipe laying can begin or to lay one kilometre of pipe before refill can 
begin. Figure 9.13 shows how these overlapping activities might appear in an AON network using the 
standard finish-to-start approach. 


9.7.2 Use of leads and lags 


The use of leads and lags has been developed to offer greater flexibility in network (and schedule) 
development. There are two types: delay (lag) and overlap (lead). 


Delay is indicated by a positive value and is called lag time. It specifies that the successor task 
will start only after X number of days or the predecessor task is completed (e.g. based on finish- 
to-start relationship). A lag directs a successor activity to be delayed. 

— Lag time is a delay between activities that have a dependency. For example, if you need a two-day 


delay between the finish of one activity and the start of another, you can establish a finish-to-start 
dependency and specify two days of lag time. 


— Note: In Microsoft Project, enter the lag time as a pesitive value. 
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Lay pipe Lay pipe Lay pipe 
1/3 1/3 1/3 
Refill Refill Refill 
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m Overlap is indicated by a negative value and is called lead time. It specifies that the successor 
activity will start X number of days before the predecessor task is completed (e.g. based on 
finish-to-start relationship). A lead allows acceleration of a successor activity. 


—Lead-time is the overlap between activities that have a dependency. For example, if an activity can 
start when its predecessor is half finished, you can specify a finish-to-start dependency with a lead- 
time of 50 per cent for the successor activity. 


— Note: In Microsoft Project, enter the lead-time as a negative value. 


The use of ‘leads’ and ‘lags’ in project networks occurs for two primary reasons. When activities of 
long duration delay the start or finish of successor activities, the network designer normally breaks 
the activity into smaller activities to avoid the long delay of the successor activity; leads and lags can 
be used to constrain the start and finish of an activity. 

The most commonly used relationship types are finish-to-start (FS), start-to-start (SS), finish- 
to-finish (FF) and (the rarely used) start-to-finish (SF). These relationship types are discussed next. 


9.7.3 Network relationship types 


This next section discusses a number of relationship types. Although these relationship types are 
discussed from a network perspective, you can equally apply these to the Gantt chart. As a student 
of project management, consider constructing a more complex network diagram and then move this 
diagram into a software package, such as Microsoft Project. The relationship types below have been 
constructed froma generic perspective and include examples for lag times—you could apply the lead- 
time perspective equally to these examples. 


FINISH-TO-START (FS) RELATIONSHIP 


The finishto-start relationship represents the 
typical, generic network style used in the early 
part of the chapter. The generic finishto-start 
relationship is illustrated in Figure 9.14. 
FS—Finish-Start. Activity B There are situations however where the next 
cannot start before © esas 
Activity A has finished. activity in a sequence must be delayed even 


when the preceding activity is complete. For 





os I i te fi Activity B 
You have two activities, ‘Activity A—Dig foundations’ and eampt ae concrete forms (Activity B) 
‘Activity B—Pour concrete’. cannot begin until the poured cement has cured 

for two time units (Activity A). Figure 9.14B 


‘Activity B—Pour concrete’ cannot begin until the ‘Activity A— shows this lag relationship. Finish-to-start lags 
Dig foundations’ has been completed. are frequently used when ordering materials. For 
example, it may take one day to place orders 
but take 19 days to receive the goods. The use of 
, z FS—Finish-Start. There is a © finish-to-start allows the activity duration to be 

lag of 19 days before Í 
Lag 19 Activity B can start. only one day and the lag 19 days. This approach 
ensures the activity cost is tied to placing the 
order only, rather than charging the activity for 


FS—Finish-Start. There is a © 20 days of work. This same finish-to-start lag 
lead of 2 days where 


Activity B can overlap with 
Lead 2 Activity A. legal and mail lags. In Figure 9.14C, Activity B 


(the successor task) will start two days before 
the predecessor activity being completed. 


relationship is useful to depict transportation, 


The use of finish-to-start leads and lags 
should be carefully checked to ensure their 
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validity. Conservative project managers, 
or those responsible for the completion of 
activities, have been known to use lags as a 
means of building in a ‘slush/padding’ factor 
to reduce the risk of being late. A simple rule 
to follow is that the use of finish-to-start lags 





Activity A starts. The dependent activity can 
begin anytime after the activity that it depends 
on begins. The SS link type does not require 
that both activities begin simultaneously. 


SS - Start-Start. Activity B cannot start until © 


must be justified and approved by someone 
responsible for a large section of the project. 
The legitimacy of lags is not usually difficult 
to discern. The legitimate use of the additional 
relationship shown can greatly enhance the 
network by more closely representing the 
realities of the project. 





Example. 


If you have two activities Activity A—Pour concrete’ and 
‘Activity B—Level concrete’. 


‘Activity B—Level concrete’ cannot begin until the ‘Activity A— 
Pour concrete’ begins. 





START-TO-START (SS) RELATIONSHIP Activity Q cannot start 
` ; n ea until 5 days after activity P 
An alternative to segmenting the activities has begun. 


as we did earlier is to use a start-to-start 
relationship. The generic start-to-start bags 
relationship is illustrated in Figure 9.15A. 
Typical start-to-start relationships are 
shown in Figure 9.15. Figure 9.15A shows the 
startto-start relationship with zero lag, while 
Figure 9.15B shows the same relationship 
with a lag of five time units. It is important to 


note that the relationship may be used with or 


Figure 9.16 





without a lag. If time is assigned, it is usually 
shown on the dependency arrow of an AON 
network (or the line joining the activities on a 
Gantt chart). Lag 3 

In Figure 9.15B, Activity Q cannot begin 

until five time units after Activity P begins. 

This type of relationship typically depicts a Lag3 

situation in which you can perform a portion 

of one activity and begin a following activity 

before completing the first. This relationship 

could be used on the pipetaying project, for example (refer Figure 9.16). The start-to-start relationship 
can reduce project delays by using lag relationships. 

It is possible to find compression opportunities by changing finish-to-start relationships to start 
to-start relationships. A review of finish-to-start critical activities may point out opportunities that, 
can be revised to be parallel, by using start-to-start relationships. For example, in place of a finish-to- 
start activity ‘design house, then build foundation’, a start-to-start relationship could be used in which 
the foundation can be started, say, five days (lag) after design has started—assuming the design 
of the foundation is the first part of the total design activity. This start-to-start relationship with a 
small lag allows a sequential activity to be worked on in parallel and compression of the duration of 
the critical path. This technique is referred to as fast tracking and is further described later in this 
chapter. This same concept is frequently found in projects in which concurrent engineering is used 
to speed completion of a project. Start-to-start relationships can depict the concurrent. engineering 
conditions and reduce network detail. Of course, the same result can be accomplished by breaking an 
activity into small packages that can be implemented in parallel, but this latter approach increases the 
network and tracking detail significantly. 
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FINISH-TO-FINISH (FF) RELATIONSHIP 


The generic relationship is found in Figure 9.17A. The finish of one activity depends on the finish of 
another activity. In Figure 9.17B, a lag has been introduced where, for example, the activity of ‘testing’ 
cannot be completed any earlier than four time units after the ‘prototype’ activity is complete. 


START-TO-FINISH (SF) RELATIONSHIP 


This relationship represents situations in which the ‘finish’ of an activity depends on the start of 
another activity (refer to Figure 9.18A). For example, system documentation cannot end until three 
time units after testing has started (see Figure 9.18B). Here, all the relevant information to complete 
the system documentation is produced after the first three days of testing. 


Figure 917 Finish-to-finish relationship 





7 


Example. 


FF—Finish—Finish. Activity B cannot 
finish until Activity A finishes. The 
dependent activity can be completed 
anytime after the activity that it 
depends on is completed. The FF link 
type does not require that both 
activities be completed simultaneously. 


© 


You have two activities, ‘Activity A—Add wiring’ and ‘Activity B— 


Inspect electrical’ 


‘Activity B—Inspect electrical’ cannot be completed until the 
‘Activity A—Add wiring’ is completed. 


Lag 4 


n 
em 


Figure 948 Start-to-finish relationship 





B 





The dependent activity (B) cannot be completed until 
the activity that it depends on (A) begins. 

The dependent activity can be completed anytime after 
the activity that it depends on begins. The SF link type 
does not require that the dependent activity be 
completed concurrent with the beginning of the activity 


on which it depends. 


Example, the roof trusses for your construction project are built 
offsite. Two of the activities in your project are ‘Activity A— 
Assemble roof’ and ‘Activity B—Truss delivery’. 


‘Activity A—Assemble roof’ cannot be completed until ‘Activity B— 


Truss delivery’ activity begins. 





mi Lag 3 System documentation cannot end until 


3 days after testing has started. 


© 
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COMBINATIONS OF LAG RELATIONSHIPS 


More than one type of lag relationship can be attached to an activity. 
These relationships are usually startto-start and finish-to-finish 
combinations tied to two activities. For example, the ‘debug’ activity 
cannot begin until two time units after the ‘coding’ activity has started. 
Coding must be finished four time units before debug can be finished 
(refer to Figure 9.19). 


Figure 919 Combination re 





AN EXAMPLE USING LAG RELATIONSHIPS: THE FORWARD 
AND BACKWARD PASS 


The forward and backward pass procedures are the same as explained earlier in the chapter for 
finish-to-start relationships (without lags). The modifying technique lies in the need to check each 
new relationship to see if it alters the start or finish time of another activity. 

An example of the outcome of the forward and backward pass is shown in Figure 9.20. Order 
hardware depends upon the design of the system (star t-to-start). Three days into the design of the 
system (Activity A), it is possible to order the required hardware (Activity B). It takes four days after 
the order is placed (Activity B) for the hardware to arrive so it can begin to be installed (Activity C). 
After two days of installing the software system (Activity B), the testing of the system can begin 
(Activity E). System testing (Activity E) can be completed two days after the software is installed 
(Activity B). Preparing system documentation (Activity F) can begin once the design is completed 
(Activity A), but it cannot be completed until two days after testing the system (Activity E). This final 


relationship is an example of a finish-to-finish lag. 


Figure 9.20 Network using lags 
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SNAPSHOT FROM PRACTICE Hammock activities 





Hammock activities are frequently used to identify the use 
of fixed resources or costs over a segment of the project. 
Typical examples of hammock activities are inspection 
services, consultants or construction management 
services. A hammock activity derives its duration from 
the time span between other activities. For example, a 
special colour copy machine is needed for a segment of a 
tradeshow publication project. A hammock activity can be 
used to indicate the need for this resource ane to apply 
costs over this segment of the project. This hammock is 
linked from the start of the first activity in the segment 
that uses the colour copy machine to the end of the last 
activity that uses it. The hammock duration is simply the 
difference between the EF for the last activity and the 
ES of the first activity. The duration is calculated after the 
forward pass and hence has no influence on other activity 


Hammock activit 


Figure 9.21 


times. Figure 9.21 provides an example of a hammock 
activity used in a network. The duration for the hammock 
activity is derived from the early start of Activity B and the 
early finish of Activity F; that is, the difference between 
13 and 5, or eight time units. The hammock duration will 
change if any ES or EF in the chain-sequence changes. 
Hammock activities are very useful in assigning and 
controlling indirect project costs. 

Another major use of hammock activities is to 
aggregate sections of a project. This is similar to 
developing a subnetwork, but the precedence is still 
preserved. This approach is sometimes used to present a 
‘macro network’ for upper management levels. Applying 
a hammock activity to group activities can facilitate 
getting the right level of detail for specific sections of 
a project. 
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Note how an activity can have a critical finish and/or start. Activities E and F have critical finishes 
(zero slack), but their activity starts have four and 12 days of slack. It is only the finish of Activities 
E and F that are critical. Conversely, Activity A has zero slack to start but has five days of slack to 
finish. The critical path follows activity start and finish constraints that occur due to the use of the 
additional relationships available and the imposed lags. You can identify the critical path in Figure 9.20 
by following the dashed line on the network. 
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If a lag relationship exists, each activity must be checked to see if the start or finish is constrained. 
For example, in the forward pass, the EF of Activity E (test system) (18) is controlled by the finish of 
Activity D (install software) and the lag of two time units (16 + lag 2 = 18). Finally, in the backward 
pass, the LS of Activity A (design system) is controlled by Activity B (order hardware) and the lag 
relationship to Activity A (3 — 3 = 0). 


HAMMOCK ACTIVITIES 


Another of the extended techniques uses a hammock activity. This type of activity derives its name 
because it spans over a segment of a project. The hammock activity duration is determined after the 
network plan is drawn. Snapshot from Practice: Hammock activities describes how the hammock 
activity is used. 


9.8 REDUCING PROJECT DURATION 


This section of the chapter addresses strategies for reducing project duration, either prior to setting 
the project’s schedule baseline (usually a gate in the project life cycle after the Planning stage) for 
the project, or in the midst of project Executing stage (in response to a change request that impacts 
the project’s schedule and requires a ‘rebaseline’). The choice of options available will be based 
upon the constraints surrounding the project. It is here that the Project Priority Matrix (introduced in 
Chapter 7) comes into play. For example, there are many more options available for reducing project 
time if you are not resourceconstrained. We will begin first by examining the reasons for reducing 
project duration and this will be followed by a discussion of the different potential options available 
for accelerating project completion. The chapter will conclude by looking at the classic time-cost 
framework for selecting which activities to ‘crash’. Crash is a term that has emerged in the project 
management lexicon for shortening the duration of an activity or project beyond when it can be 
normally done. 


9.8.1 Rationale for reducing project duration 


There are many good reasons for attempting to reduce the duration of a project. One of the more 
important reasons cited today is ‘time to market’. Intense global competition and rapid technological 
advances have made speed a competitive advantage. To succeed, companies have to spot new 
opportunities, launch project teams, and bring new products or services to the marketplace in a flash. 
Perhaps in no other industry does speed matter as much as in the electronics industry. For example, 
arule of thumb for moderate- to high-technology firms is that a sixmonth delay in bringing a product 
to market can result in a loss of market share of about 35 per cent. In these cases, hightechnology 
firms typically assume that time savings and avoidance of lost profits are worth any additional costs 
to reduce time without any formal analysis. 

Business survival depends not only upon rapid innovation but also on adaptability. Global recessions 
and sudden energy crises often take the business world by surprise; the companies that survive will 
be those that can quickly adapt to new challenges. This requires speedy project management! For 
example, the fate of the US car industry depends, in part, on how quickly the (domestic) industry 
shifts its efforts to develop fuel-efficient, alternative forms of transportation. 

Another common reason for reducing project time occurs when unforeseen delays (e.g. adverse 
weather, design flaws, equipment breakdown) cause substantial delays midway in the project. Getting 
back on schedule usually requires compressing the time of some of the remaining critical activities. 
The additional costs of getting back on schedule need to be compared with the consequences of being 
late. This is especially true when time is a top priority. 

Incentive contracts can make reducing a project’s duration rewarding—usually for both the project 
contractor and owner. For example, a contractor finished a bridge across a lake 18 months early and 
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received more than $6 million for its early completion. The availability of the bridge to the surrounding 
community 18 months early to reduce traffic gridlock made the incentive cost to the community seem 
small to users. In another example, in a continuous improvement arrangement, the joint effort of the 
owner and contractor resulted in early completion of a river lock and a 50/50 split of the savings to the 
owner and contractor. 

‘Imposed deadlines’ is another reason for accelerating project completion. For example, 
a politician makes a public statement that a new law building will be available in two years, or 
the director of a software company remarks in a speech that new advanced software will be 
available in one year. Such statements often become ‘imposed’ project duration dates—without 
much consideration being given to the problems or costs arising from having to meet the date. The 
project duration time is set while the project is in its ‘concept’ stage—before or without any detailed 
scheduling of all the activities in the project. This phenomenon occurs very frequently in practice. 
Unfortunately, this practice almost always leads to a higher cost project than one that is planned 
using low-cost and detailed planning. In addition, quality is sometimes compromised to meet 
deadlines. More importantly, the increased costs of imposed duration dates are seldom recognised 
or noted by project participants. 

Sometimes very high overhead costs are recognised before the project begins. In these cases it is 
prudent to examine the direct costs of shortening the critical path versus the overhead cost savings. 
Usually there are opportunities to shorten a few critical activities at less than the daily overhead rate. 
Under specific conditions (which are not rare), huge savings are possible with minimum risk. 

Finally, there are times when it is important to reassign key equipment and/or people to new 
projects. Under these circumstances, the cost of compressing the project can be compared with the 
opportunity-costs of not releasing key equipment or people. 


9.9 OPTIONS FOR ACCELERATING PROJECT 
COMPLETION 


Project managers have several effective methods for reducing the duration of specific project activities 
when resources are not constrained; these are summarised below. 


9.9.1 Options when resources are not constrained 
CRASHING (ADDING RESOURCES) 


The most common method for shortening project time is to assign additional staff and equipment 
(resources) to activities (crashing the project schedule). However, there are limits as to how much 
speed can be gained by adding staff. Doubling the size of the workforce will not necessarily reduce 
completion time by half. The relationship would be correct only when tasks can be partitioned so 
minimal communication is needed between workers (as in harvesting a crop by hand, or resurfacing 
a highway). Most projects are not set up this way; having additional workers necessitates increasing 
the communication requirements to coordinate their efforts. For example, doubling a team by adding 
two workers requires six times as much, pair-wise, intercommunication than is required in the original 
two-person team. Not only is more time needed to coordinate and manage a larger team, there is the 
additional delay of training the new people and getting them up-to-speed on the project. The end result 
is captured in Brooks’ law: ‘Adding manpower to a late software project makes it later’. Frederick 
Brooks formulated this principle based on his experience as a project manager for IBM's System/360 
software project during the early 1960s. While subsequent research confirmed Brooks’ prediction, it 
also discovered that adding more people to a late project does not always cause the project to be 
further delayed. The linchpin is whether new staff are added early on, so there is sufficient time to 
make up for lost ground once the new members have been fully assimilated. Remember: ‘Crashing’ 
tends to lead to increased cost and increased risk. 
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OUTSOURCING PROJECT WORK 


A common method for shortening the project time is to subcontract an activity. The subcontractor may 
have access to superior technology or expertise that will accelerate the completion of the activity. 
For example, contracting for a backhoe could accomplish in two hours what it can take a team of 
labourers two days to do. Likewise, by hiring a consulting firm that specialises in .Net programming, 
a firm may be able to cut the time in half it would take for less experienced, internal programmers to 
do the work. Subcontracting also frees up resources that can be assigned to a critical activity and will 
ideally result in shorter project duration. Outsourcing is addressed more fully in Chapter 18. 


SCHEDULING OVERTIME 


The easiest way to add more labour to a project is not to add more people, but to schedule overtime. 
If a team works 5@ hours a week instead of 40, it might accomplish 2@ per cent more. By scheduling 
overtime, it may be possible to avoid the additional costs of coordination and communication 
encountered when new people are added. If the personnel involved are salaried workers, there may 
be no real additional cost for the extra work. Another advantage is that there are usually fewer 
distractions when people work outside normal hours. 

Overtime has its disadvantages. First, hourly workers may be paid time-anda-half for overtime 
and double time for weekends and holidays. Sustained overtime work by salaried employees may 
incur intangible personal costs (e.g. divorce, burnout, turnover). The latter is a key organisational 
concern when there is a shortage of workers. Furthermore, it is an oversimplification to assume that, 
over an extended period of time, a person will be as productive during their eleventh hour at work 
as they are during their third hour of work. There are natural limits to what is humanly possible, and 
extended overtime may actually lead to an overall decline in productivity when fatigue sets in. 

Overtime and working longer hours is the preferred choice for accelerating project completion, 
especially when the project team is salaried. The key is to use overtime judiciously. Remember that 
a project is a marathon and not a sprint! You do not want to run out of energy before the finish line. 


ESTABLISH A CORE PROJECT TEAM 


One of the advantages of creating a dedicated core team to complete a project is speed. Assigning 
professionals fulltime to a project avoids the hidden cost of multitasking in which people are forced 
to juggle the demands of multiple projects. Professionals are allowed to devote their undivided 
attention to a specific project. This singular focus creates a shared goal that can bind a diverse set 
of professionals into a highly cohesive team capable of accelerating project completion. Factors 
that. contribute to the emergence of high-performing project teams will be discussed in detail in later 
chapters. 


DO IT TWICE, FAST AND THEN CORRECTLY 


If you are in a hurry, try building a ‘quick and dirty’ shor tterm solution (or prototype), and then go 
back and do it the right way. For example, the Sydney Olympics used this strategy when finalising 
the Sydney Olympics’ volleyball tournament. This was originally slated to be held in an inside 
venue; however, a temporary stadium was constructed on the world-famous Bondi Beach with over 
10 000 seats. 


9.9.2 Options when resources are constrained 


A project manager has fewer options for accelerating project completion when additional resources 
are either not available or the budget is severely constrained. This is especially true once the schedule 
has been established. Below are some of these options, which are also available when resources are 
not constrained. 
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FAST TRACKING 


Sometimes it is possible to rearrange the logic of the project network so that critical activities are 
done in parallel (concurrently) rather than sequentially. This alternative is a good one if the project 
situation is right. When this alternative is given serious attention, itis amazing to observe how creative 
project team members can be in finding ways to restructure sequential activities in parallel. As noted 
earlier in this chapter, one of the most common methods for restructuring activities is to change a 
finish-to-start relationship to a stertto-start relationship. For example, instead of waiting for the final 
design to be approved, manufacturing engineers can begin building the production line as soon as key 
specifications have been established. Changing activities from sequential to parallel usually requires 
closer coordination among those responsible for the activities affected but can produce tremendous 
time savings. Remember: ‘Fast-tracking’ tends to lead to a decrease in cost but an increase in risk. 


CRITICAL-CHAIN PROJECT MANAGEMENT 


Critical-chain project management (CCPM) is designed to accelerate project completion. As discussed 
in Appendix 7.2 (online), the jury is still out in terms of its applicability. Still, CCPM principles appear 
sound and worthy of experimentation if speed is essential. At the same time, it would be difficult to 
apply CCPM midstream in a project. CCPM requires considerable training and a shift in habits and 
perspectives that take time to adopt. Although there have been reports of immediate gains, especially 
in terms of completion times, a long-term management commitment is probably necessary to reap full 
benefits. See Snapshot from Practice: The fastest house in the world for an extreme example of CCPM 
application. 


REDUCING PROJECT SCOPE 


Probably the most common response for meeting unattainable deadlines is to reduce or scale back 
the scope of the project. This invariably leads to a reduction in the functionality of the project. For 
example, the new car will average only 7.8 L/10@ km instead of 9.4, or the software product will have 
fewer features than originally planned. While scaling back the scope of the project can lead to big 
savings in both time and money, it may come at a cost of reducing the value of the project. If the 
car gets lower mileage, will it stand up to competitive models? Will customers still want the software 
minus the features? 

The key to reducing a project scope without reducing value is to reassess the true specifications 
of the project. Often requirements are added under ‘best-case’, ‘blue-sky’ scenarios and represent 
desirables, but not essentials. Here it is important to talk to the customer and/or project sponsors and 
explain the situation—‘You can get it your way but not until February’. This may force the customer to 
accept an extension or to add money to expedite the project. If not, then a healthy discussion needs to 
take place regarding what the essential requirements are and what items can be compromised in order 
to meet the deadline. A more intense re-examination of requirements may actually improve the value 
of the project by getting it done more quickly and for a lower cost. 

Calculating the savings of the reduced project scope begins with the WBS. Reducing functionality 
means certain tasks, deliverables or requirements can be reduced or even eliminated. These tasks need 
to be found and the schedule adjusted. Focus should be on changes in activities on the critical path. 


COMPROMISING QUALITY 

Reducing quality is always an option, but it is rarely acceptable (or used). If quality is sacrificed, 
it may be possible to reduce the time of an activity on the critical path. Some car manufacturers 
will compromise on quality in production (for a known problem), and then carry out a recall at the 
dealership before the car hits the road. This can be more economical than stopping the manufacturing 
chain. Reducing the quality can save enormously; for example, the cost increase from 95 per cent 
perfect to 100 per cent perfect is a geometric increase. Additionally, some manufacturers will produce 
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SNAPSHOT FROM PRACTICE The fastest house in the world 





17 December 2002—After revving up their power tools 
and lining up willing volunteers, Shelby County’s Habitat for 
Humanity broke the world record for the fastest house ever 
built, clocking in at 3 hours, 26 minutes and 34 seconds. 
The former record holder (New Zealand's Habitat Affiliate 
Mannakau) had held the record for three years at 3 hours, 
44 minutes and 59 seconds. The Alabama project beat 
the New Zealand record by 18 minutes. 

‘This was different than any construction project that 
I've ever been a part of; said project manager Chad 
Calhoun. ‘The minute-by-minute schedule, the planning of 
each precise movement, the organisation of all the teams 
and materials could not have gone more smoothly on 
build day. All the long hours of planning definitely paid off’ 

In preparation for the build, Habitat volunteers put the 
foundation in place and constructed prefabricated wall 
panels. Once the whistle blew at 11:00amon 17 December, 
the exterior wall panels were raised into place, followed 
by the interior panel, which took only 16 minutes. Special 
colour-coded teams of workers connected the wiring 
and plumbing, put in insulation, installed appliances, laid 
carpeting and tiles, installed light fixtures, painted the 
house inside, applied vinyl siding outside and attached 





At the same time, the roof was constructed on the 
ground nextto the house. Once the roof was completed— 
approximately 1% hours later—a Steel City crane lifted 
the 6350-kg roof assembly into place. Crews attached 
the roof while others completed the interior work. There 
was even time to lay sod, plant shrubbery and decorate 
a Christmas tree in the front yard—all within the official 
build time of 3 hours, 26 minutes and 34 seconds. 

The recipient of this gift was Bonnie Lilly, a single 
mother and nursing technician who had applied to 
Habitat for Humanity three times before she was 
selected to receive the three-bedroom, two-bath home. 
‘It’s amazing,’ Lilly said. ‘Who am | to have this happen 
for me? A world record, hundreds of people coming 
together to build my house—| still can’t believe it’ 

Habitat for Humanity is an international charitable 
organisation that builds simple, affordable houses and 
sells them on a no-interest, no-profit basis to needy 
families. 


Source: Drummond E 2002, ‘Shelby county habitat for humanity breaks 
world record’, CSR Wire, www.csrwire.com/press_releases/24660-The- 
House-T hatLove-BuiltReally-FAS TAndJustin-TimeforChristmas-Kicker- 
HabitatFor-Humanity -BreaksWorld-Record-Set-By-New-Zealang, accessed 


assembled front and back porches. February 2018. 


products that have lower cost versions to meet lower cost offerings to different consumer groups; 
for example, Ford in Australia offers the smaller, lower cost Ford Fiesta, but at the higher end offers 
customised cars such as the revered Falcon XR6 Turbo. 

In practice, the methods most commonly used to crash projects are scheduling overtime, 
outsourcing and adding resources. Each of these maintains the essence of the original plan. Options 
that. depart from the original project plan include ‘do it twice’ and ‘fast-tracking’. Rethinking project 
scope, customer needs and timing becomes a major consideration for these techniques. 

A time-lapse video for one of the Habitat for Humanity can be found at the following link: https// 
www.youtube.com/watch?v=AwEcW6h HB8. 


9.9.3 What if cost, not time, is the issue? 


In today’s fast-paced world, there appears to be a greater emphasis on getting things done quickly. 
Organisations are always looking for ways to get things done cheaper. This is especially true for 
fixed-bid projects, where the profit. margin is derived from the difference between the bid and the 
actual cost of the project. Every dollar saved is a dollar in your pocket. Sometimes, in order to secure 
a contract, bid margins are very tight, which puts added pressure on cost containment. In other cases, 
there may be financial incentives tied to cost containment. 

Even in situations where costs are transferred to customers, there remains the pressure to reduce 
cost. Cost overruns make for unhappy customers and can damage future business opportunities. 
Budgets can be fixed or cut, and when contingency funds are exhausted, cost overruns have to be 
made up with remaining activities. 
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As discussed earlier, shortening the project duration may come at the expense of overtime, adding 
additional personnel and using more expensive equipment and/or materials. Conversely, sometimes 
cost savings can be generated by extending the duration of a project. This may allow the use of a 
smaller workforce, lessskilled (expensive) labour, and even cheaper equipment and materials. Below 
are some of the more commonly used options for cutting costs. 


REDUCE PROJECT SCOPE 


Just as scaling back the scope of the project can gain time, delivering less than what was originally 
planned also produces significant savings. Again, calculating the savings of a reduced project scope 
begins with the WBS. However, since time is not the issue, you do not need to focus on critical activities. 
For example, on overbudget movie projects it is not uncommon to replace location shots with stock 
footage to cut costs. 


HAVE OWNER TAKE ON MORE RESPONSIBILITY 


One way of reducing project costs is to identify tasks that customers can do themselves. Homeowners 
frequently use this method to reduce costs on home improvement projects. For example, to reduce the 
cost of a bathroom remodel, a homeowner may agree to paint the room instead of paying the contractor 
to do it. On information system projects, a customer may agree to take on some of the responsibility 
for testing equipment or providing inhouse training. Naturally, this arrangement. is best negotiated 
before the project begins. Customers are less receptive to this idea if you suddenly spring it on them. 
An advantage of this method is that, while costs are lowered, the original scope is retained. Clearly, this 
option is limited to areas in which the customer has expertise and the capability to pick up the tasks. 


OUTSOURCING PROJECT ACTIVITIES OR EVEN THE ENTIRE PROJECT 


When estimates exceed the available budget, it not only makes sense to re-examine the scope but also 
search for cheaper ways to complete the project. Perhaps instead of relying on internal resources, it 
would be more costeffective to outsource segments, or even the entire project, by opening up work 
to external price competition. Specialised subcontractors often enjoy unique advantages, such as 
material discounts for large quantities, as well as equipment that not only gets the work done more 
quickly, but also less expensively. They may have lower overhead and labour costs. For example, 
to reduce costs of software projects, many Australian firms outsource work to firms operating in 
India, where the salary of a software engineer is a fraction of that of an Australian software engineer. 
However, outsourcing means you have less control over the project and will need to have clearly 
definable deliverables. 


BRAINSTORMING COST-SAVINGS OPTIONS 


Just as project team members can be a rich source of ideas for accelerating project activities, they can 
similarly offer tangible ways for reducing project costs. For example, one project manager reported 
that his team was able to come up with over $75 000 worth of costsaving suggestions, without 
jeopardising the scope of the project. Project managers should not underestimate the value of simply 
asking if there is a cheaper, better, simpler way. 


9.10 THE RESOURCE SCHEDULING PROBLEM 


After staff and other resources were assigned to her project, a project manager listed the following 
questions that still needed to be addressed: 


@ Will the assigned labour and/or equipment be adequate and available to deal with my project? 


@ Will outside contractors have to be used? 
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Figure 9.22 
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@ Do unforeseen resource dependencies exist? Is there a new critical path? 
m How much flexibility do we have in using resources? 


Æ Is the original deadline realistic? 


Clearly, this project manager has a good understanding of the problems she is facing. Any project 
scheduling system should facilitate finding quick, easy answers to these questions. 

The planned network and activity project duration times found in previous chapters fail to deal 
with resource usage and availability. The time estimates for the work packages and network times 
were made independently with the implicit assumption that resources would be available. This may or 
may not be the case. 

If resources are adequate but the demand varies widely over the life of the project, it may be 
desirable to even out resource demand by delaying noncritical activities (using slack) to lower peak 
demand and, thus, increase resource utilisation. This process is called resource smoothing. 

On the other hand, if resources are not adequate to meet peak demands, the late start of some 
activities must be delayed, and the duration of the project may be increased. This process is called 
resource-constrained scheduling. 

The consequences of failing to schedule limited resources are costly and project delays usually 
manifest themselves midway through the project when quick corrective action is difficult. An 
additional consequence of failing to schedule resources is ignoring the peaks and valleys of resource 
usage over the duration of the project. Because project resources are usually overcommitted and 
because resources seldom line up by availability and need, procedures are needed to deal with these 
problems. This chapter addresses methods available to project managers for dealing with resource 
utilisation and availability through resource levelling and resourceconstrained scheduling. 

Up to now, the start and sequence of activities has been based solely on technical or logical 
considerations. For example, a project network for framing a house might show three activities in 
a sequence: (1) pour foundation, (2) build frame and (8) cover roof. A network for a new software 
project could place the activities in the network, as a sequence of (1) design, (2) code and (3) test. 
In other words, you cannot logically perform Activity 2 until 1 is completed, and so on. The project 
network depicts technical constraints (see Figure 9.23A). The network assumes the personnel and 
equipment are available to perform the required work. This is often not the case. 

The absence or shortage of resources can drastically alter technical constraints. A project network 
planner may assume adequate resources and show activities occurring in parallel. However, parallel 
activities hold potential for resource conflicts. For example, assume you are planning a wedding 
reception that includes four activities—(1) plan, (2) hire band, (3) decorate hall and (4) purchase 
refreshments. Each activity takes one day. Activities 2, 3 and 4 could be done in parallel by different 
people. There is no technical reason or dependency of one on another (see Figure 9.23B). However, 
if one person must perform all activities, the resource constraint requires the activities be performed 
in sequence or series. Clearly the consequence is a delay of these activities and a very different set of 
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Figure 9.23 Constraint examples 
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network relationships (see Figure 9.23C). Note that the resource dependency takes priority over the 
technological dependency but does not violate the technological dependency; that is, hire, decorate 
and purchase may now have to take place in sequence rather than concurrently, but they must all be 
completed before the reception can take place. 

The interrelationships and interactions among time and resource constraints are complex for 
even small project networks. Some effort to examine these interactions before the project begins 
frequently uncovers surprising problems. Project managers who do not consider resource availability 
in moderately complex projects usually learn of the problem when it is too late to correct. A deficit of 
resources can significantly alter project dependency relationships, completion dates and project costs. 
Project managers must be careful to schedule resources to ensure availability in the right quantities 
and at the right time. Fortunately, there are computer software programs that can identify resource 
problems during the early project Planning stage when corrective changes can be considered. These 
programs only require activity resource needs and availability information to schedule resources. 

See Snapshot from Practice: Working in tight places for a third constraint that impinges on project 
schedules. 


9.10.1 Types of resource constraints 


Resources are people, equipment and material that can be drawn on to accomplish something. In 
projects the availability or unavailability of resources will often influence the way projects are 
managed. 


1. People: This is the most obvious and important project resource. Human resources are usually 
classified by the skills they bring to the project—for example, programmer, mechanical engineer, 
welder, inspector, marketing director, supervisor. In rare cases, some skills are interchangeable, 
but usually with a loss of productivity. The many differing skills of human resources add to the 
complexity of scheduling projects. 
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SNAPSHOT FROM PRACTICE Working in tight places 





In rare situations, physical factors cause activities that would 
normally occur in parallel to be constrained by contractual 
or environmental conditions. For example, in theory the 
renovation of asailboat compartment might involve four to five 
tasks that can be done independently. However, since space 
allows only one person to work at one time, all tasks have to 
be performed sequentially. Likewise, on a mining project it 


may be physically possible for only two miners to work in a 
shaft at a time. Another example would be the erection of 
a communication tower and nearby groundwork. For safety 
considerations, the contract prohibits groundwork within 
610 metres of the tower construction. 

The procedures for handling physical factors are 
similar to those used for resource constraints. 


2. Materials: Project materials cover a large spectrum—for example, chemicals for a scientific 
project, concrete for a road project or survey data for a marketing project. Material availability 
and shortages have been blamed for the delay of many projects. When it is known that a lack of 
availability of materials is important and probable, materials should be included in the project 
network plan and schedule. For example, delivery and placement of an oil rig tower in a Siberian 
oil field has a very small time window during one summer month. Any delivery delay means a 
oneyear, costly delay. Another example in which material was the major resource scheduled was 
the resurfacing and replacement of some structures on the Golden Gate Bridge in San Francisco. 
Work on the project was limited to the hours between midnight and 5am witha penalty of 
US$1000 per minute for any work taking place after 5 am. Scheduling the arrival of replacement 
structures was an extremely important part of managing the five-hour work-time window of the 
project. Scheduling materials has also become important in developing products where time to 
market can result in loss of market share. 


3. Equipment: Equipment is usually presented by type, size and quantity. In some cases equipment 
can be interchanged to improve schedules, but this is not typical. Equipment is often overlooked 
as a constraint. The most common oversight is to assume the resource pool is more than adequate 
for the project. For example, if a project needs one earthmoving tractor six months from now 
and the organisation owns four, it is common to assume the resource will not delay the pending 
project. However, when the earthmoving tractor is due onsite in six months, all four machines in 
the pool might be occupied on other projects. In multiproject environments, it is prudent to use 
a common resource pool for all projects. This approach forces a check of resource availability 
across all projects and reserves the equipment for specific project needs in the future. Recognition 
of equipment constraints before the project begins can avoid high crashing or delay costs. 


9.10.2 Classification of a scheduling problem 


Most of the scheduling methods available today require the project manager to classify the project 
as either time constrained or resource constrained. Project managers need to consult their Project 
Priority Matrix (see Chapter 7, Figure 7.6) to determine which case fits their project. One simple test 
to determine if the project is time or resource constrained is to ask, ‘If the critical path is delayed, 
will resources be added to get back on schedule?’ If the answer is yes, assume the project is time 
constrained; if no, assume the project is resource constrained. 

A time-constrained project is one that must be completed by an imposed date. If required, 
resources can be added to ensure the project is completed by a specific date. Although time is the 
critical factor, resource usage should be no more than is necessary and sufficient. 

A resource-constrained project is one that assumes the level of resources available cannot be 
exceeded. If the resources are inadequate, it will be acceptable to delay the project, but.as little as possible. 
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In scheduling terms, time constrained means time (project duration) is fixed and resources are 
flexible, while resource constrained means resources are fixed and time is flexible. Methods for 
scheduling these projects are presented in the next section. 


9.11 RESOURCE ALLOCATION METHODS 


The rest of the chapter depends entirely on the assumptions noted here. First, splitting activities will 
not be allowed. This means once an activity is placed in the schedule, assume it will be worked on 
continuously until it is finished; hence, an activity cannot be started, stopped for a period of time and 
then finished. Second, the level of resources used for an activity cannot be changed. These limiting 
assumptions do not exist in practice, but simplify learning. It is easy for new project managers to 
deal with the reality of splitting activities and changing the level of resources when they meet them 
on the job. 


9.11.1 Time-constrained projects: smoothing resource demand 


Scheduling time-constrained projects focuses on resource utilisation. When demand for a specific 
resource type is erratic, it is difficult to manage and utilisation may be very poor. Practitioners 
have attacked the utilisation problem using resource-levelling techniques that balance demand for 
a resource. Basically, all levelling techniques delay non-critical activities by using positive slack to 
reduce peak demand and fill in the valleys for the resources. An example will demonstrate the basic 
procedure for a time-constrained project (see Figure 9.24). 

For the purpose of demonstration, the Botanical Garden project uses only one resource, 
backhoes; all backhoes are interchangeable. The top bar chart shows the activities on a time scale. 
The dependencies are shown with the vertical connecting arrows. The horizontal arrows following 
activities represent activity slack (e.g. irrigation requires six days to complete and has six days 
slack). The number of backhoes needed for each task is shown in the shaded activity duration block 
(rectangle). After the land has been scarified and the plan laid out, work can begin on the walkways, 
irrigation, and fencing and retaining walls simultaneously. The middle chart shows the resource 
profile for the backhoes. For periods 4 through 10, four backhoes are needed. 

Because this project is declared time constrained, the goal will be to reduce the peak requirement 
for the resource and thereby increase the utilisation of the resource. A quick examination of the ES 
(early start) resource load chart suggests only two activities have slack that can be used to reduce the 
peak—fence and walls provide the best choice for smoothing the resource needs. Another choice could 
be irrigation, but it would result in an up-and-down resource profile. The choice will probably centre 
on the activity that is perceived as having the least risk of being late. The smoothed resource-loading 
chart shows the results of delaying the fence and walls activity. Note the differences in the resource 
profiles. The important point is the resources needed over the life of the project have been reduced 
from four to three (25%). In addition the profile has been smoothed, which should be easier to manage. 

The Botanical Garden project schedule reached the three goals of smoothing: 


1. The peak of demand for the resource was reduced. 


v 


Resources over the life of the project were reduced. 


3. The fluctuations in resource demand were minimised. 


The latter improves the utilisation of resources. Backhoes are not easily moved from location to 
location. There are costs associated with changing the level of resources needed. The same analogy 
applies to the movement of people back and forth among projects. It is well known that people are 
more efficient if they can focus their effort on one project rather than multitasking their time among, 
say, three projects. 

The downside of levelling is a loss of flexibility that occurs from reducing slack. The risk of 
activities delaying the project also increases because slack reduction can create more critical activities 
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Figure 9.24 Botanical Garden 
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and/or near-critical activities. Pushing levelling too far for a perfectly level resource profile is risky. 
Every activity then becomes critical. 

The Botanical Garden example gives a sense of the time-constrained problem and the smoothing 
approach. However, in practice the magnitude of the problem is very complex for even small projects. 
Manual solutions are not practical. Fortunately, the software packages available today have very 
good routines for levelling project resources. Typically, they use activities that have the most slack 
to level project resources. The rationale is those activities with the most slack pose the least risk. 
Although this is generally true, other risk factors—such as reduction of flexibility to use reassigned 
resources on other activities, or the nature of the activity (easy, complex)—are not addressed using 
such a simple rationale. It is easy to experiment with many alternatives to find the one that best fits 
your project and minimises risk of delaying the project. 
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9.11.2 Resource-constrained projects 


When the number of people and/or equipment is not adequate to meet peak demand requirements and 
it is impossible to obtain more, the project manager faces a resource-constrained problem. Something 
has to give. The trick is to prioritise and allocate resources to minimise project delay without exceeding 
the resource limit or altering the technical network relationships. 

The resource-scheduling problem is a large combinatorial one. This means even a modest-size 
project network with only a few resource types might have several thousand feasible solutions. A few 
researchers have demonstrated optimum mathematical solutions to the resource allocation problem 
but only for small networks and very few resource types. The massive data requirements for larger 
problems make pure mathematical solutions (e.g. linear prograraming) impractical. An alternative 
approach to the problem has been the use of heuristics (rules of thumb) to solve large combinatorial 
problems. These practical decision or priority rules have been in place for many years. 

Heuristics do not always yield an optimal schedule, but they are very capable of yielding a ‘good’ 
schedule for very complex networks with many types of resources. The efficiency of different rules 
and combinations of rules has been well documented. However, because each project is unique, it 
is wise to test several sets of heuristics on a network to determine the priority allocation rules that 
minimise project delay. The computer software available today makes it very easy for the project 
manager to create a good resource schedule for the project. A simple example of the heuristic 
approach is illustrated here. 

Heuristics allocate resources to activities to minimise project delay; that is, heuristics prioritise which 
activities are allocated resources and which activities are delayed when resources are not adequate. 

The parallel method is the most widely used approach to apply heuristics, which have been found 
to consistently minimise project delay over a large variety of projects; see Table 9.3. The parallel 
method is an iterative process that starts from the beginning of project time and, when resources 
needed exceed the resources available, retains activities first by the priority rules: 


Rule 1 Minimum slack. 
Rule 2 Smallest duration. 


Rule 3 Lowest activity identification number. 


Those activities not able to be scheduled without delaying others are pushed out farther in time. 
However, do not attempt to move activities that have already started. When considering activities not 
to delay, consider the resources each activity uses. In any period when two or more activities require 
the same resource, the priority rules are applied. For example, if in period 5 three activities are 
eligible to start (i.e. have the same ES) and require the same resource, the first activity placed in 
the schedule would be the activity with the least slack (Rule 1). However, if all activities have the 
same slack, the next rule would be invoked (Rule 2) and the activity with the smallest duration would 
be placed in the schedule first. In very rare cases, when all eligible activities have the same slack and 
the same duration, the tie is broken by the lowest activity identification number (Rule 3), since each 
activity has a unique ID number. 

When a resource limit has been reached, the early start (ES) for succeeding activities not yet in the 
schedule will be delayed (and all successor activities not having free slack) and their slack reduced. In 
subsequent periods the procedure is repeated until the project is scheduled. The procedure is demonstrated 
next; see Figure 9.25. The shaded areas in the resource-loading chart represent the ‘scheduling interval’ 
of the time-constrained schedule (ES through LF). You can schedule the resource any place within the 
interval and not delay the project. Scheduling the activity beyond the LF will delay the project. 

The programmers are limited to three. Follow the actions described in Figures 9.25 and 9.26. Note 
how the limit of three programmers starts to delay the project. 

Observe how itis necessary to update each period to reflect changes in activity early start and slack 
times so the heuristics can reflect changing priorities. When using the parallelscheduling method, the 
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Figure 9.25 Re: hedule through pe 
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Figure 9.26 Reso 
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Table 9.3 The parallel method 


rererere rererere 
See Figure 9.25 


0-1 Only activity 1 is eligible. It requires 2 programmers. 
Load activity 1 into schedule. 
No activities are eligible to be scheduled. 

2-3 Activities 2, 3 and 4 are eligible to be scheduled. Activity 3 has the least slack (0)—apply rule 1. 
Load activity 3 into schedule. 


Activity 2 is next with slack of 2; however, activity 2 requires 2 programmers and only 1 is 
available. 


Delay activity 2. Update: ES = 3, slack = 1. 
The next eligible activity is activity 4, since it only requires 1 programmer. 
Load activity 4 into schedule. 


See Figure 9.26 


3-4 Activity 2 is eligible but exceeds limit of 3 programmers in pool. 
Delay activity 2. Update: ES = 4, slack = 0. 
4-5 Activity 2 is eligible but exceeds limit of 3 programmers in pool. 


Delay activity 2. Update: ES = 5, LF = 11, slack = —1. 
Delay activity 7. Update: ES = 11, LF = 13, slack = —1. 
5-6 Activity 2 is eligible but exceeds limit of 3 programmers in pool. 
Delay activity 2. Update: ES = 6, LF = 12, slack = —2. 
Delay activity 7. Update: ES = 12, LF = 14, slack = —2. 
6-7 Activities 2, 5 and 6 are eligible with slack of —2, 2 and O, respectively. 
Load activity 2 into schedule (Rule 1). 
Because activity 6 has O slack, it is the next eligible activity. Load activity 6 into schedule (Rule 1). 
The programmer limit of 3 is reached. 
Delay activity 5. Update: ES = 7, slack = 1. 


7-8 Limit is reached. No programmers available. 

Delay activity 5. Update: ES = 8, slack = 0. 
8-9 Limit is reached. No programmers available. 

Delay activity 5. Update: ES = 9, LF = 11, slack = —1. 
9-10 Limit is reached. No programmers available. 

Delay activity 5. Update: ES = 10, LF = 12, slack = —2. 
10-11 Activity Sis eligible. 


Load activity 5 into schedule. 

(Note: Activity 6 does not have slack because there are no programmers available—3 maximum.) 
11-12 No eligible activities. 
12-13 Activity 7 is eligible. 

Load activity 7 into schedule. 


network in Figure 9.26 reflects the new schedule date of 14 time units, rather than the time-constrained 
project duration of 12 time units. The network has also been revised to reflect new start, finish and 
slack times for each activity. Note that Activity 6 is still critical and has a slack of @ time units because 
no resources are available (they are being used on Activities 2 and 5). Compare the slack for each 
activity found in Figures 9.25 and 9.26; slack has been reduced significantly. Note that Activity 4 has 
only two units of slack rather than what appears to be six slack units. This occurs because only three 
programmers are available, and they are needed to satisfy the resource requirements of Activities 
2 and 5. Note that the number of critical activities (1, 2, 3, 5, 6, 7) has increased from four to six. 

This small example demonstrates the scenario of scheduling resources in real projects and the 
resulting increase in the risk of being late. In practice this is not a trivial problem. Managers who fail 
to schedule resources usually encounter this scheduling risk when it is too late to work around the 
problem, resulting in a project delay. 
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Since manually using the parallel method is impractical on real-world projects because of size, 
project managers will depend on software programs to schedule project resources. 


9.11.3 The impacts of resource-constrained scheduling 


Like levelling schedules, the limited resource schedule usually reduces slack, reduces flexibility by 
using slack to ensure delay is minimised and increases the number of critical and nearcritical activities. 
Scheduling complexity is increased because resource constraints are added to technical constraints; 
start times may now have two constraints. The traditional critical path concept of sequential activities 
from the start to the end of the project is no longer meaningful. The resource constraints can break 
the sequence and leave the network with a set of disjointed critical activities. Conversely, parallel 
activities can become sequential. Activities with slack on a time-constrained network can change 
from critical to noncritical. 


9.12 SPLITTING ACTIVITIES 


Splitting tasks is a scheduling technique used to get a better project schedule and/or to increase 
resource utilisation. A planner splits the continuous work included in an activity by interrupting the 
work and sending the resource to another activity for a period of time and then having the resource 
resume work on the original activity. Splitting can be a useful tool if the work involved does not 
include large start-up or shutdown costs—for example, moving equipment from one activity location 
to another. The most common error is to interrupt ‘people work’, where there are high conceptual 
startup and shutdown costs. For example, having a bridge designer take time off to work on the 
design problem of another project may cause this individual to lose four days shifting conceptual 
gears in and out. of two activities. The cost may be hidden, but it is real. Figure 9.27 depicts the nature 
of the splitting problem. The original activity has been split into three separate activities: A, B and C. 
The shutdown and start-up times lengthen the time for the original activity. 

Some have argued that the propensity to deal with resource shortages by splitting is a major 
reason why projects fail to meet schedule. We agree. Planners should avoid the use of splitting as 


Figure 9.27 Splitting activities 














Activity duration without splitting 





Activity A Activity B Activity C 











Activity duration split into three segments—A, B, C 





Activity A Activity B 


A 


tot 
Shutdown Start-up 


Activity duration split with shutdown and start-up 


Activity C 














CHAPTER 9 PROJECT SCHEDULE MANAGEMENT 


SNAPSHOT FROM PRACTICE Assessing resource allocation 





One of the strengths of today's project management (ii) Check the sensitivity of the network and ask if 

software is the ability to identify and provide options for this is acceptable. 

resolving resource allocation problems. A project manager If not: 

who uses Microsoft Project to plan projects shared with us c) considering splitting tasks. 

the following checklist for dealing with resource conflicts (i) Make sure to readjust task durations to take 

after preliminary assignment of resources has been made. into account additional start-up and shutdown 
time. 


1. Assess whether you have over-allocation problems 

(see Red in the resource sheet view). 

2. Identify where and when conflicts occur by examining 
the resource usage view. 
3. Resolve the problem by: 

(a) replacing over-allocated resources with appropriate 
resources that are available. Then ask if this solves 
the problem. 

If not: 

(b) using the levelling tool and choosing the level 
within slack option. 

(i) Does this solve the problem? (Are resources still 
over-allocated?) 


4. If 3does not work then: 

a) use level tool default option and ask if you can 
live with the new completion date. 

f not: 

b) negotiate for additional resources to complete 
the project. If not possible: 

c) consider reducing project scope to meet 
deadline. 
While this checklist makes specific references to 

Microsoft Project, the same steps can be used with most 

project management software. 





much as pessible, except in situatiens where splitting cests are knewn te be small er when there is ne 
alternative fer reselving the reseurce preblem. Cemputer seftware effers the splitting eptien fer each 
activity; use it sparingly. See Snapshet frem Practice: Assessing reseurce allecatien. 


9.13 BENEFITS OF SCHEDULING RESOURCES 


It is important to remember that, if resources are truly limited and activity time estimates are accurate, 
the resourceconstrained schedule wil! materialise as the project is implemented—not the time 
constrained schedule! Therefore, failure to schedule limited resources can lead to serious problems 
for a project manager. Creating this schedule before the project begins leaves time for considering 
reasonable alternatives. If the scheduled delay is unacceptable or the risk of being delayed too 
high, the assumption of being resource constrained can be reassessed. Cost—time trade-offs can be 
considered. In some cases, priorities may be changed. 

Resource schedules provide the information needed to prepare timephased work package 
budgets with dates. Once established, they provide a quick means for a project manager to gauge 
the impact of unforeseen events such as turnover, equipment breakdowns or transfer of project 
personnel. Resource schedules also allow project managers to assess how much flexibility they have 
over certain resources. This is useful when they receive requests from other managers to borrow or 
share resources. Honouring such requests creates goodwill and an ‘IOU’ that can be cashed in during 
a time of need. 


9.14 ASSIGNING PROJECT WORK 


When making individual assignments, project managers should match, as best they can, the demands 
and requirements of specific work with the qualifications and experience of available participants. In 
doing so, there is a natural tendency to assign the best people the most difficult tasks. Project managers 
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need to be careful not to overdo this. Over time these people may grow to resent the fact that they are 
always given the toughest assignments. At the same time, less experienced participants may resent the 
fact that they are never given the opportunity to expand their skill/knowledge base. Project managers 
need to balance task performance with the need to develop the talents of people assigned to the project. 

Project managers not only need to decide who does what, but who works with whom. A number of 
factors need to be considered in deciding who should work together. First, to minimise unnecessary 
tension, managers should pick people with compatible work habits and personalities but who complement 
each other (i.e. one person's weakness is the other person's strength). For example, one person may be 
brilliant at solving complex problems but sloppy at documenting his or her progress. It would be wise 
to pair this person with an individual who is good at paying attention to detail. Experience is another 
factor. Veterans should be teamed up with new hires—not only so they can share their experience but 
also to help socialise the newcomers to the customs and norms of the organisation. Finally, future 
needs should be considered. If managers have some people who have never worked together before but 
who have to later on in the project, they may be wise to take advantage of opportunities to have these 
people work together early on so that they can become familiar with each other. 


9.15 MULTI-PROJECT RESOURCE SCHEDULES 


For clarity we have discussed key resource allocation issues within the context of a single project. 
In reality, resource allocation generally occurs in a multi-project environment where the demands 
of one project have to be reconciled with the needs of other projects. Organisations must develop 
and manage systems for efficiently allocating and scheduling resources across several projects with 
different priorities, resource requirements, sets of activities and risks. The system must be dynamic 
and capable of accommodating new projects as well as re-allocating resources once project work is 
completed. While the same resource issues and principles that apply to a single project also apply to 
this multiproject environment, application and solutions are more complex, given the interdependency 
among projects. 

The following lists three of the more common problems encountered in managing multi-project 
resource schedules. Note that these are macro manifestations of single-project problems that are now 
magnified in a multi-project environment: 


1. Overall schedule slippage: Because projects often share resources, delays in one project can have 
a ripple effect and delay other projects. For example, work on one software development project 
can grind to a halt because the coders scheduled for the next critical task are late in completing 
their work on another development project. 


2. Inefficient resource utilisation: Because projects have different schedules and requirements, 
there are peaks and valleys in overall resource demands. For example, a firm may have a staff 
of 10 electricians to meet peak demands when, under normal conditions, only five electricians 
are required. In the construction industry you can improve efficiency and resource allocation by 
understanding the difference in the effective operation of each machine—for example, moving 
dirt up to 100 metres is much more efficient with a bulldozer than a scraper (100-500 metres) or a 
dump truck (500 + metres). 


3. Resource bottlenecks: Delays and schedules are extended as a result of shortages of critical 
resources that are required by multiple projects. For example, at one Lattice Semiconductor 
facility, project schedules were delayed because of competition over access to test equipment 
necessary to debug programs. Likewise, several projects at.a forest commission area were 
extended because there was only one silviculturist on the staff. 


To deal with these problems, more and more companies create project offices or departments 
to oversee the scheduling of resources across multiple projects. One approach to multiple project 
resource scheduling is to use a firstcome—tirstserved rule. A project queue system is created in which 
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projects currently underway take precedence over new projects. New project schedules are based on 
the projected availability of resources. This queuing tends to lead to more reliable completion estimates 
and is preferred on contracted projects that have stiff penalties for being late. The disadvantages of 
this deceptively simple approach are that it does not optimally utilise resources or take into account. 
the priority of the project. 

Many companies utilise more elaborate processes for scheduling resources toincrease the capacity of 
the organisation to initiate projects. Most of these methods approach the problem by treating individual 
projects as part of one big project and adapting the scheduling heuristics previously introduced to this 
‘megaproject. Project schedulers monitor resource usage and provide updated schedules based on 
progress and resource availability across all projects. One major improvement in project management. 
software in recent years is the ability to prioritise resource allocation to specific projects. Projects can 
be prioritised in ascending order (e.g. 1, 2, 3, 4), and these priorities will override scheduling heuristics 
so that resources go to the project highest on the priority list. (Note that this improvement fits perfectly 
with organisations that use project prioritisation models similar to those described in Chapter 4.) 
Centralised project scheduling also makes it easier to identify resource bottlenecks that stifle progress 
on projects. Once identified, the impact of the bottlenecks can be documented and used to justify 
acquiring additional equipment, recruiting critical personnel or delaying the project. 

Finally, many companies are using outsourcing as a means for dealing with their resource 
allocation problems. In some cases, a company will reduce the number of projects they have to manage 
internally to only core projects and outsource noncritical projects to contractors and consulting 
firms. In other cases, specific segments of projects are outsourced to overcome resource deficiencies 
and scheduling problems. Companies may hire temporary workers to expedite certain activities that 
are falling behind schedule or contract project work during peak periods when there are insufficient 
internal resources to meet the demands of all projects. The ability to more efficiently manage the ebbs 
and flows of project work is one of the major driving forces behind outsourcing today. 


9.16 USING THE RESOURCE SCHEDULE TO DEVELOP 
A PROJECT COST BASELINE 


Once resource assignments have been finalised, we are able to develop a baseline budget forthe project. 
Using your project schedule, you can time-phase work packages and assign them to their respective 
scheduled activities to develop a budget schedule over the life of your project. Understanding the 
reason for time-phasing your budget is very important. Without a time-phased budget, good project 
schedule and cost control are impossible. Chapter 10 tackles this subject further. 


9.17 SCRUM/AGILE CONSIDERATIONS 


The Scrum (Agile) requirements for a project schedule are limited. It is however, possible that. the 
product owner, in conjunction with the Scrum master, creates an epic, increment and sprint view of 
the entire project once a product backlog has been established (refer Chapter 3, Figure 3.6). 

This would be a ‘best-attempt schedule’ of the timing of these highlevel Scrum events, as the 
product owner will not know what is possible within a sprint until a number of sprints have been 
delivered and the overall velocity of a sprint is known. The same approach might also be taken when 
designing a Large-Scale Scrum (LeSS) implementation—building a highlevel schedule of products, 
epics, increments and sprints. 

At a more granular level (once the sprint planning event has produced the sprint backlog), the 
sprint burndown (or sprint burnup) chart tracks the ‘story points’ completed against each of the 
stories ona daily basis. The Scrum master and product owner can monitor sprint progress through the 
use of these sprint burndown (or sprint burnup) charts. 

Refer to Chapter 3 for further details on the terminology used in this short section. 
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Summary 


Many project managers feel the project network (schedule) is their most valuable project planning document. It is, in 
‘act, just one of many documents that can be used to capture the project manager and project team’s ‘thinking’. This 
chapter has introduced: 


The importance of establishing governance, policy and processes around the planning of schedule management 
across the life cycle of the project. This more static information is typically captured in the Schedule Management 
Plan—one of the subsidiary plans to the Project Management Plan. 

This chapter has also introduced the concept of project networks as a way of fundamentally understanding how 
activities in the project are scheduled. Every project manager should feel comfortable building an activity-on-node 
AON) network for their project. 

The AON is a more visual representation of the project schedule and the project manager should be able to switch 
tween both the AON and the project schedule (Gantt chart) to manage (and optimise) the project’s schedule of 
activities. Some project managers take this a step further by regularly exporting the project schedule back into a 
WBS format, to provide a truly visual representation of the project. 

A number of techniques were introduced for reducing the overall project schedule. These included the two key 
techniques of crashing—adding additional resources (usually to activities on the critical path) to shorten the duration 
of activities; and fæst tracking—reviewing activities to ascertain opportunities for carrying out previously sequential 
activities to more in parallel (the degree of overlap might be just part of the whole activity’s duration). 





The project manager must be on top of the project’s schedule as this makes up one of the baselines (i.e. the schedule 
baseline) against which changes to the project are assessed to ensure scope creep does not occur from a schedule 
perspective. As illustrated in this chapter, project schedule management involves more than just successfully pulling 
together a Gantt chart (using a tool such as Microsoft Project). Instead, project schedule management requires a 
deeper understanding of how to leverage theory of relationship types, crashing, fast-tracking, and other techniques to 
successfully deliver the project within a realistic timeframe. 


https://en.wikipedia.org/wiki/Comparison_of_project_management_software 
https://www.youtube.com/user/SirGanttalot 
https://www.apm.org.uk/body-of-knowledge/delivery/schedule-management/ 
https://www.pmi.org/learning/library/pro ject-dev elopment-schedule-management-plan-6205 
https://www.pmi.org/pmbok-guide-standards/framework/practice-standard-scheduling-2ndedition 


activity hammock activity project network 
activity-on-arrow (AOA) heuristics resource-constrained project 
activity-on-node (AON) laddering resource-constrained scheduling 
burst activity lag relationship resource smoothing 
concurrent engineering lags sensitivity 

crashing leads slack/float (total) 

critical path levelling splitting 

dangler merge activity time-constrained project 
fast-tracking Parallel activity schedule baseline 

free slack Parallel/sequence activities Schedule Management Plan 
Gantt chart path 


Review questions 


E 


How does the WBS differ from the project network? 


2. How are WBS and project networks linked? 
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bother creating a WBS? Why not go straight to a project network and forget the WBS? 
hy is ‘slack’ important to the project manager? 

at is the difference between ‘free slack’ and ‘total slack’? 

hy are ‘lags’ used in developing project networks? 

at is a ‘hammock activity’, and when is it used? 

at are five common reasons for ‘crashing’ a project? 


PpMOrnanaw 
Saseeceeee 


at are the advantages and disadvantages of reducing 
duce the disadvantages? 


roject scope to accelerate a project? What can be done to 





y is scheduling overtime a popular choice for getting projects back on schedule? What are the potential problems 
for relying on this option? 


11. Reducing the project duration increases the risk of being late. Explain. 





12. How does resource scheduling reduce flexibility in managing projects? 

13. How can outsourcing project work alleviate the three most common problems associated with multi-project resource 
scheduling? 

14. Explain the risks associated with levelling resources, compressing or crashing projects, and imposed durations or 


‘catch-up’ as the project is being implemented. 


4. Draw a project network from the following information. Which activity is a ‘burst’ activity? Which activity is a ‘merge’ 
activity? 


ID Description Predecessor 
A Identify topic None 

B Research topic A 

G Draft paper B 

D Edit paper € 

E Create graphics € 

[= References ce 

G Final draft D EF 


2. Draw a project network from the following information. Which activity is a ‘burst’ activity? Which activity is a ‘merge’ 
activity? 


D | Desc! Predecessor 


A Contract signed None 
B Survey designed A 

(6 Target market identified B 

D Data collection B.C 

E Develop presentation B 

a Analyse results D 

G Demographics ic 

H Presentation EEG 


3. From the following information, develop an AON project network. Complete the forward and backward pass, calculate 
activity slack and identify the critical path. How many days will the project take? 


ID Description 
A Survey site None Z 
B Install drainage A 5 
Ç Install power lines A 3 
D Excavate site B.C 4 
E Pour foundation D 3 


PART 3 DEFINING AND MANAGING PROJECTS 


4. The project information for the custom order project of the Air Control Company is presented here. Draw a project 
network for this project. Calculate the early and late activity times and the slack times. Identify the critical path. 





iD | Activity Time 
A Order review None 2 
B Order standard parts A 15 
E Produce standard parts A 10 
D Design custom parts A 13 
E Software development A 18 
F Manufacture custom C, D 15 

hardware 
Assemble B,F 10 
H Test EG 5 


5. You have signed a contract to build a garage for the Simpsons. You will receive an A$500 bonus for completing the 
project within 15 working days. The contract also contains a penalty clause stating that you will lose A$100 for each 
day the project takes longer than 15 working days. 

Draw a project network given the information below. Complete the forward and backward pass, calculate the activity 
slack, and identify the critical path. Do you expect to receive a bonus or a penalty on this project? 


iD | Description Predecessor Time (days) 


A Pour foundation None 3 
B Erect frame A 4 
€ Roof B 4 
D Windows B 1 
E Doors B 1 
F Electrical B 3 
G Rough-in frame DME T= 2 
H Door opener EF i 
l Paint G, H 2 
J Cleanup | 1 


6. J. Smith (Project Manager for Print Software Pty Ltd) wants you to prepare a project network. Calculate the early, late and 
slack activity times. Determine the planned project duration and identify the critical path. His assistant has collected the 
following information for the Colour Printer Driver's Software Project: 


‘ip | Description Predecessor Time 
A External specifications None 8 
B Review design features A 2 
E Document new features A 3 
D Write software A 60 
E Program and test B 60 
E Edit and publish notes G Z 
G Review manual D 2 
H Alpha site EE 20 
I Print manual G 10 
al] Beta site H, | 10 
K Manufacture J 12 
L Release and ship K 3 


7. A large city in Victoria is requesting federal funding for a park-and-ride project. One of the requirements in the ‘request’ 
application is a network plan for the design stage of the project. Catherine Walker, the chief engineer, wants you 
to develop a Project Network Plan to meet this requirement. She has gathered the activity time estimates and their 
dependencies, as shown here. Show your project network with the activity early, late and slack times. Mark the critical 
path. 
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ID |Description Predecessor Time 
A Survey None 5 
B Soils report A 20 
(e Traffic design A 30 
D Lot layout A 5 
E Approve design BCD 80 
F Illumination E 15 
G Drainage E 30 
H Landscape E 25 
l Signing E 20 
J Bid proposal FGHI 10 


8. The planning department of an electronics firm has set up activities for the development and production of a new MP3 
player. Given the information below, develop a project network. 


ID Activity description Activity Activity time 
predecessor |(weeks) 


1 Staff None 2 
2 Develop market program 1 3 
3 Select channels of distribution 1 8 
4 Patent il 12 
5 Pilot production 1 4 
6 Test market 5 4 
a Ad promotion 2 4 
8 Set up for production 4,6 16 


The project team has requested that you create a network for the project, and determine whether the project can be 

completed in 45 weeks. 

9. The optical disk project team has started gathering information that is necessary for developing the project network 
(predecessor activities and activity times, in weeks). The results of their meeting are found in the following table. 


Activity | Description Duration 
1 


Define scope 6 None 
2 Define customer problems Ei 1 
3 Define data records and relationships 5 1 
4 Mass storage requirements 5 Z3 
5 Consultant needs analysis 10 PAE] 
6 Prepare installation network = 45 
7 Estimate costs and budget 2 45 
8 Design section ‘point’ system 1 45 
9 Write request proposal 5 45 
10 Compile vendor list 3 4,5 
11 Prepare mgmt. control system S 67 
12 Prepare comparison report 5 eka] 
13 Compare system ‘philosophies’ 3 8,12 
14 Compare total installation 2 8,12 
15 Compare cost of support 3} tele 
16 Compare customer satisfaction level 10 8,12 
17 Assign philosophies points 1 13 
18 Assign installation cost 1 14 
19 Assign support cost 1 15 
20 Assign customer satisfaction points 1 16 
21 Select best system 1 ‘de aA 2X8) 
22 Order system 1 21 


The project team has requested that you create a network for the project and determine if the project can be completed 
in 45 weeks. 
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10. Draw the project network from the following information. Calculate the early, late and slack times for each activity. 
Identify the critical path. (Hint: Draw the finish-to-start relationships first.) 










Activity | Description Duration 
Finish-to-start [Finishto-start _ |AdditionalLagiD | Duration | Predecessor Lag [Relationships Lag 
A 5 None o None ie} 
B 10 A ie} None ie} 
Cc 15 A o Start-finish C to D 20 
D 5 B 5 Start-start D to E 5 
Finish-finish D to E 25 
E 20 B ie) Finish—finish E to F o 
F 15 D o None o 
G 10 (E 10 Finish—finish G to F 10 
H 20 FF ie) None o 


11. Given the information in the following lag exercises, calculate the early, late and slack times for the project network. 
Which activities on the critical path have only the start or finish of the activity on the critical path? 


ID | Duration _|Finish-to-start predecessor 
A 5 None ie} None ie} 

B 10 A ie} None ie} 

Cc 15 A o Start—finish C to D 20 

D 5 B 5 Start-start D to E 5 

Finish—finish D to E 25 

E 20 B ie) Finish—-finish E to F O 

F 15 D ie} None ie} 

G 10 C 10 Finish-finish G to F 10 

H 20 F ie} None ie} 


12. Draw a project network from the following information. 


Activity Predecessor Duration 


A None zA 
B A 4 
E A 3 
D A 2 
E B 3 
(= jG 6 
G Ep 5 
H EF 6 
| G 5 
J H, [ 5 


Activities B and H can be shortened to a minimum of two weeks. Which activity would you shorten to reduce the 
project duration by two weeks? Why? 


13. Given the data and information that follow, calculate the total direct cost for each project duration. If the indirect costs 
for each project duration are $90 (15 time units), $70 (14), $50 (13), $40 (12) and $30 (11), calculate the total project 
cost for each duration. What is the optimum cost—time schedule for the project? What is this cost? 


Activity | Crash cost (slope) Normal time Normal cost 


A 20 1 5 50 
B 60 2 3 60 
C ie} o 4 70 
D 10 1 2 50 
E 60 3 5 100 
E 100 1 2 90 
G 30 1 si 50 
H 40 ie} 2 60 
l 200 il 3 200 


$730 
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44. Ifthe indirect costs for each duration are $300 for 27 weeks, $240 for 26 weeks, $180 for 25 weeks, $120 for 
24 weeks, $60 for 23 weeks and $50 for 22 weeks, calculate the direct, indirect and total costs for each duration. 
Whatis the optimum cost—time schedule? The customer offers you $10 for every week you shorten the project from 
your original network. Would you take it? If so, for how many weeks? 


Activity | Crash cost (slope) Maximum crash time Normal time Normal cost 








A 80 2 10 40 
B 30 3 8 10 
[s 40 1 5 80 
D 50 2 11 50 
E 100 4 15 100 
E 30 1 6 20 
$300 
Time unit = 1 week 
A D 
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15. You have prepared the following schedule for a project in which the key resource is a tractor. There are three tractors 
available to the project. Activities A and D require one tractor to complete while Activities B, C, E and F require two 
tractors. 


Develop a resource-constrained schedule in the loading chart that follows. Use the parallel method and heuristics 
given. Be sure to update each period as the computer would do. Record the early start (ES), late finish (LF) and slack 
(SL) for the new schedule. 








Legend 
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Use the following heuristics: 
Minimum slack 
Smallest duration 
Lowest identification number 
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16. Develop a resource schedule in the loading chart that follows. Use the parallel method and heuristics given. Be sure 
to update each period as the computer would do. Note: Activities 2, 3,5 and 6 use two of the resource skills. Three of 
the resource skills are available. How has s/ack changed for each activity? Has the risk of being late changed? How? 




































































8 | 6 | 10 
[0] 1 Oo o E Oo 
O° ||| 2 3 3 Be 8 B| 2 10 
o 2 o 
33 3 3 5/6 
Eg aa 2 
5 B38: 
Use the following heuristics: List the order in which your 
Minimum slack activities are scheduled 


Smallest duration 
Lowest identification number 








ID’ RES DURES LF SLO 1 2 3 4 5 6 7 8 SOA l as 





















































Resources scheduled 





Resources available 









































What is the schedule slack for 1 ne] and4 fe 
Which activities are critical now? 


Additional case studies, exercises (including solutions to selected exercises) and appendices are available 
online. 
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PROJECT COST MANAGEMENT 





Learning elements 


Be able to successfully plan project cost management. 
Have an understanding of how project costs are arrived at. 
Be able to construct a time-phased project budget. 
Understand and set project contingency. 

Understand how to control project costs. 


Be aware of considerations for completing and closing cost management activities. 


In this chapter 


10.1 Introduction 

10.2 Early considerations for project cost management 
10.3 Cost management plan 

10.4 Identification of costs 

10.5 Estimation of costs 

10.6 Simple time-phased project budgets 

10.7 Project cost control and monitoring 

10.8 Cost closure 

10.9 Scrum/Agile considerations 


Summary 
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10.1 INTRODUCTION 


Project cost management includes many facets of budgeting, including the planning of costs, the 
estimating of costs against the work breakdown structure (WBS) and other artefacts generated, the 
presentation of the costs in a format that. can be understood by the project management. office (PMO) 
and management, the controlling of costs, and the reporting of costs. The goal is to have a structured 
presentation of data and information, at.a suitable level of detail, which will enable the project manager— 
later in the project life cycle—to track spend, and analyse and report on any variances (PMI 2017). 

This chapter covers the subject of project cost management; the reader should note that a number 
of topics relevant to this chapter are covered in other chapters (refer to Figure 10.1): 


m Cost estimating was discussed in Chapter 8 along with the different techniques that can be 
applied in the estimating of costs (e.g. analogous, parametric, estimating tools). 


Em Resource identification is covered in Chapter 13, including a discussion of activities that. 
are carried out to identify the resources (e.g. human, materials, tools, equipment) needed to 
successfully complete the project—these are inputs into the cost estimating discussion that must 
be costed to be included in the projects budget. 


Æ Cost control and cost reporting are discussed in Chapter 11. Discussions encompass the inclusion 
of cost reporting in project status reports. 


E Scheduling work packages was covered in Chapter 9, and this topic considers when costs will be 
incurred and how these will be met (i.e. whether the project has sufficient funds to meet outgoing 
costs). 


In practice, these key activities are carried out simultaneously and complement. each other. This 
chapter brings together the linkages between the above activities into a cohesive process for the 
project manager to follow. 


10.2 EARLY CONSIDERATIONS FOR PROJECT 
COST MANAGEMENT 


From a project perspective, cost management includes: 


Em The identification and estimation of costs, identified from the WBS and the WBS dictionary. 


Cost estimating 
Chapter & 








Cost control and cost Project cost i i 
reporting management Resource identification 
Chapter 11 (this chapter) Chapter 13 


Scheduling work 


packages 
Chapter 9 
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@ The capturing and estimation of other project costs, identified through the development of the 
project's subsidiary plans and supporting artefacts/documents, for example: 


— Scope: What is the relationship between the scope of the project and the environment within 
which the project is to operate—is there, for example, the requirement to have a large amount of 
contingency? 


— Risk: Are there any costs associated with mitigating risks (e.g. insurance costs) or in avoiding risk 
completely by introducing new work packages into the design of the project with an associated cost? 
How is the contingency for the project influenced by the project’s overall risk? 


— @uality: Chapter 12 discusses the cost of quality (CoQ) to a project. There are obvious implications 
to costs when considering quality: higher quality parts and additional quality-related steps within 
the work packages equate to higher costs. 


— Communications: Depending on the project, there could potentially be large costs associated with 
project communications. For example, on projects requiring considerable community stakeholder 
engagement, the costs for venue hire, publicity and travel must be factored in, and so too the costs 
associated with using print media (newspapers and journals), social media, and other web plat- 
forms to reach the targeted audience. 


— Human resource and other resource requirements obviously add costs to the project (e.g. the 
hiring of contractors for a project). However, the cost of training and development, project team- 
building activities, and bonus and retention payments also need to be included. Costs such as these 
are often overlooked. 


— Procurement: The costs associated with schedules of payments, contractor payments and other 
costs associated with procuring products and/or services to the project (at the correct time-point in 
the project's schedule). 

As set out above, costs can arise from many sources across the life cycle of a project, and from any 
of the 10 knowledge areas covered in this text. During the Initiating stage of the project, the project 
manager needs to particularly consider the costs of large capital items and long lead-time items. 


10.2.1 Large capital items 


The project manager should specifically identify any large capital items that will have to be procured 
for the project. Large capital items may require a number of special considerations due to: 


E The scale of the cost of the items: Large capital items are often investments that require 
substantial up-front outlay and their cost could exceed the total of all other project costs. 


E Approvals required for their purchase: Due to the scale of their investment, large capital items 
may need approvals outside of the organisation’s standard procurement processes: The CEO, 
executive team and company board may have to be approached to canvass approvals. 


E The complexities of procurement and negotiating contracts: Due to the scale of the 
investment/s and the type/s of purchase made, tendering, selecting suppliers, and contract 
negotiations can take extended periods of time, which need to be factored into the project's 
schedule. 


E Financial cashflow considerations: How will large capital purchases be funded? Do contracts 
necessitate substantial up-front deposits to be made (prior to the project having been approved 
at the Initiating stage and prior to project funding being released)? How and when will the 
remaining balances be paid? (i.e. via a series of staged payments or via a single large payment. 
on delivery?) The project manager will need to ensure the project has the required cash flow 
(funding) at the right times to be able to meet the cost commitments and will therefore need to 
consider this as part of the project ‘cost’ management and project ‘procurement’ management 
knowledge areas. 
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Examples of large capital items could include large bore tunnelling equipment, electrical transformers, 
heavy-duty equipment, buildings and office space, data centres (etc.) Sometimes, large capital items 
fall into the long lead-time category, meaning they are not only expensive to acquire, but also take a 
considerable amount of time to acquire and to therefore become available for use in the project. 


10.2.2 Long lead-time items 


Items that have a long lead-time must be identified early in the project life cycle. These items are typically 
required for activities on the critical path, which adds complexity. Long leadtime items need to be: 


m Identified early, as essentially, the project cannot start producing its deliverables without the 
presence of these items. Sometimes these items are identified and commitments made, preproject 
as part of the development of the Business Case. 


SNAPSHOT FROM PRACTICE Long lead-time and large capital purchases: 


The Clem Jones Tunnel (CLEM7) project 





RiverCity Motorway contracted the @esign and 
construction of this tunnel to the ‘Leighton Contractors 
ane Baulderstone Bilfinger Berger Joint Venture’ (LBB 
JV). Construction of the A$3 billion tollway commenced 
in September 2006 and was completed in March 2010: 
seven months ahead of schedule. Tunnelling on the 
CLEM7 was undertaken by two tunnel-boring machines 
(TBMs) named ‘Matilda’ ane ‘Florence’, plus several 
smaller roadheader machines. Digging the south-bound 
tunnel, Florence completed her journey from Bowen Hills 
to Woolloongabba on 16 April 2009. She was followed 
approximately six weeks later on 26 May 2009 by Matilda, 
whose breakthrough into the access shaft at Gibbon 
Street, Woolloongabba, signalled the end of tunnelling for 
the project. 

Matilda ane Florence are the largest of their type in These machines represented a significant capital purchase 
the world and excavated 75 per cent of the tunnel. The by the project. However, they were only two of many large 
tunnel-boring machines operated like a moving factory, capital items that hae long lead-times. The ventilation 
excavating the rock, erecting the concrete tunnel lining equipment also represented significant purchases. In 
and placing the road base as they went. Some of the 2008 a Rivercity Motorway investor update indicated! that 








Shuttersteck/Oleg Totsky! 


dimensions of the tunnelling machines are outline below: ‘To date, 70 percent of the final mechanical and electrical 
m cost—A$50 million per machine design has been completed and procurement is well 
advanced with all major long lead time items ordered. The 
m diameter—12.4 metres mechanical ane electrical contractor, United Group, has 
m jength—261 metres taken delivery of the first three batches of jet fans (119 in 
i total). The first three shipments of smoke dampers (28 in 
m weight—4000 tonnes total) have also arrived in Brisbane. Factory acceptance 
m cutters—78 tungsten carbide tipped 19 inch (48 tests have been continuing in Australia ane overseas for 
centimetre) disc cutters items such as ventilation outlet axial fans and transformers’. 

m =manufacturer—Herrenknecht (Germany) Source: Adapted from Queensland Government. www.brisbane.qid.govau/ 

’ traffictransport/roadsinfrastructure-b ikeways/tunnelsbridges.mapr-roads/ 

m tunnelling rate—up to 20 metres per day CLEM7/Construction-facts-figures/index.htm and Rivercity Motorway 2008, 


‘Tunnel boring machine breaks through at Kangaroo Point’, www.asx.com.au/ 
m Operating crew—22 people per shift. asxpdf/2008 1223/pdf/31fbhvzikd2dtrpef, accessed December 2012. 
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E Approved outside of the project management life cycle (i.e. approvals are obtained prior to 
project ‘kick-off’). When this occurs, there must exist a high-degree of certainty that the project is 
going to proceed into the Initiating stage and onto the Planning and Executing stages. 


For an example of the procurement of long lead-time and large capital items in a project environment, 
refer to Snapshot from Practice: Long lead-time and large capital purchases: The Clem Jones Tunnel 
(CLEM7) project. Other costs are typically identified from the WBS, the activities and the work 
packages, as will be discussed later in this chapter. 

Also often contemplated early on in the cost process is the make or buy analysis. Simply put, the 
project manager will have to make decisions about whether to ‘buy’ in components (WBS deliverables 
and/or work packages) to the project, or ‘make’ these within the project. As an example: a project might 
be considering the implementation of a payroll system and the project manager would therefore need 
to decide whether to purchase a commercial off-theshelf (COTS) package, or whether to develop a 
payroll package as part of the project. These decisions are often driven by cost, yet other factors such 
as time and risk may also be important, in which case, these factors will also need to be considered 
as a part of the make or buy decision. Chapter 18 considers the make or buy decision in further detail. 

These ‘early considerations for project cost management’ and the resulting decisions made are 
often captured in the projects Cost Management Plan, along with other information related to how 
cost management will take place in this particular project. 


10.3 COST MANAGEMENT PLAN 


The Cost Management Plan captures various information that assists in understanding how cost 
estimating was applied, and the basis of the project’s cash flow, governance, policy and procedure around 
the management. and approval of the project budget, among other information. It is a document. that 
supports the understanding of the resulting project budget and informs how the budget will be managed 
during the running of the project. The typical contents of a Cost Management Plan could include: 


@ Glossary: Definitions of all financial terms used, basis for calculations and explanations. 


E Governance, policy and procedure: As a project manager it is important to know what. 
organisational policy and procedures must be adopted into the project environment. On 
medium to large projects, it is useful to include both finance and procurement department 
representatives as stakeholders to the project. Some organisations have ‘commercial managers’ 
or similar role, through which the project manager and project team direct all questions on 
financial governance, policy and procedure. Details of the organisation’s governance, policy and 
procedure (from a financial perspective) should be clearly articulated in the Cost Management 
Plan and communicated to all members of the project team who have financial responsibilities. 
It is important not only to capture what the interactions are at the corporate levels of the 
organisation, but also what arrangements are being put in place at a local project level in relation 
to discretionary spending, such as the use of company credit cards, set spending limits and 
categories, the approval of expense claims within the project and timesheet sanctioning. 


E Contingency: This is an amount of funds allocated for events that are outside of the approved 
project budget, and includes the governance around how these funds are accessed. 


E Estimating: Any activity that is estimated should be recorded in an estimating table (typically 
a spreadsheet or tool). The estimating table would include information on the WBS reference, 
what was estimated, the estimating technique applied, what stage of the project life cycle 
it was conducted within, who carried out the estimating and who provided the estimate 
information. It is also important to document any estimating assumptions, so that when 
the source of each estimate is queried at a later stage of the project, the basis upon which 
the estimate and assumptions were made will be clear. This allows for transparency in the 
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estimating process and for lessons learned to be captured, in order to improve the current 
project and future projects. 


m Systems. Finance/Enterprise Resource Planning (ERP) systems can be complex and 
daunting for the project manager and those in the project team responsible for maintaining the 
financial information within them. Clear guidelines should be established (and communicated) 
to all those who are required to access these systems, on how to use these systems in the project 
environment. The range of access type will also vary extensively: for example, access to a time- 
sheeting module for consultants, a reporting application for the project administrator, or access 
to the wider ERP system for the project accountant in order to maintain details of work packages 
and work orders. The project manager has to become familiar with which systems are optional 
and which are mandatory for the maintenance of project cost information. The project manager 
must also ensure that a request for access to systems is initiated and that appropriate training for 
all those who have access to these systems is carried out. 


E Roles and responsibilities: Any business rules in relation to the management of cost could be 
captured in the project’s RASCI, and categorised with the tag ‘Cost/Budget’ for easy identification. 
An example of such a business rule could be ‘Expense claims greater that $100 must be 
approved’—the project manager would be both Accountable (A) and Responsible (R) and the 
Project Administrator would be Informed (I). A more detailed discussion on the RASCI Matrix is 
in Chapter 14. 


E Long lead-time and large capital items: Once identified, the requirements, value and timelines 
for acquiring long lead-time and large capital items (along with funding and approvals) should be 
documented. 


E Funding sources: Most project budgets represent. an outflow of money based on approved 
funding for the project. The approved budget for the project is typically not released in one 
chunk of funds; more frequently, funds will be released upon certain milestones being achieved, 
or by approval within the gated framework. In developing the project budget, the project 
manager must take into account the timing and sources of the funds and incorporate them 
within the project budget as cash in-flows. Although the accounting for these cash inflows 
would appear in the project budget, the details of the timing and amounts, funding sources and 
approvals would typically be documented within the Cost Management Plan. 


mg Lessons-learned. Consideration of previous projects’ lessons-learned in relation to project cost 
management and the approach taken in this project to avoid the same problems should be 
captured in the Cost Management Plan. 


Source: ® 2018 Dr Neil Pearson 





Now the basis of costing has been established, the discussion will move into the processes of 
identifying costs, estimating costs, building the time-phased budget, controlling costs and the closure 
of costs-related activities. 


10.4 IDENTIFICATION OF COSTS 


Costs can occur and be associated to almost any activity in the planning of a project. Table 10.1 
illustrates some of the sources of costs (and cost-related information) by knowledge area. 
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Table 101 Sources of costs by knowledge area 


Knowledge area 


Scope 


Time 


Cost 


Quality 


Resources 


Procurement 


Information and 


communications 


Risk 


Stakeholders 


Integration 


Sources of costs 





The scope document, WBS and work packages with all varying levels of details captured within them, depending on the 
life cycle stage of the project. These break down what is required, when and for how long, and provide essential and 
important inputs into the creation of a project budget. 

The actual costs involved in the Initiating and Planning stages of the project must also be accounted for—these are 

not free! 


Indication of ‘how long’ a resource is required for and ‘when’ the resources will be deployed. This information, when 
combined with the resource costs themselves, provides an important input into cost planning. 


The resources deployed to estimate and plan the project budget. 
The costs (time and resources) estimated in reporting and controlling costs in the project—don’t underestimate these 
activities, especially if an ERP system is used. 


Cost of quality (i.e. the costs associated with building quality activities into the project's WBS and work packages). 
Remember, there is a cost to good quality. 

The additional cost implications to the quality of the goods and/or services bought into the project. Higher quality 
goods and/or services have a higher cost. 

From a Business Case perspective, the above costs of building quality into the project can be set against the current 
costs of poor quality occurring in the process in operations at present (the CoPQ). 


Identification of all the resources required to achieve each work package. 

Note: A resource can be human or other (e.g. facilities, raw materials, plant and equipment) (PMI 2017). 
Identification of additional resources required to complete the project, not forgetting the project manager, project 
administrators (or coordinators), project accountants (to manage information in the company’s ERP system) or other 
costs associated with whole-ofJife project costs, such as rental of office space for the project team, electricity, ICT 
support and so on. 

If resources are ‘seconded’ to the project there could be a cost in recruiting the back4ill position in the business; 
these costs may be payable by the project. 


Early identification of long lead-time items and large capital items. 

The bill of materials (BoM) provides an important list of all the products and/or services required by the project to 
produce the product, service (or result) from the project. The BoM is discussed in Chapter 18. Project procurement 
Management could be an extensive list that has been assessed for the make or buy decision, and further to this may 
have been estimated. 

Any contracts where terms and conditions for payment have been agreed, even though the contract may not yet have 
been put into effect. 


Information sharing often requires ICT systems to support the collection and dissemination of project information. There 
could be a reasonably sized cost to these systems that must be accounted for in the project budget. 

Any communication activity has a cost associated with it, whether this is the resources assigned to write, review and 
distribute electronic communications or prepare print communications. Print communications could also have additional 
costs such as announcements in mainstream newspapers—costing many thousands of dollars. 

Some projects may have dedicated resources employed in respect to communications, such as a fulltime 
communications manager. 


Risks are typically assessed for costs across multiple dimensions. 

1. Any mitigation plans that have been put in place to reduce risks will take time and effort inthe project and therefore 
have a cost associated. 

2. For higher risks that cannot be reduced, there could be a potential cost to the business if they do occur and become 
active issues. The project manager may have to consider these costs in the contingency costs calculated for the project. 

If risk workshops are carried out, invited SMEs and external consultants represent costs that need to be planned and 

accounted for. 


Some stakeholder engagements can cost considerable funds. For example, say you have a town-hall meeting, open 
to members of the public, for the announcement of a new hospital wing. You'd have to hire the venue, staff the venue, 
produce quality information booklets and have a feedback mechanism in place to publish responses to questions—all 
this costs money, and for one communication only. 


Integration activities are not free to the project. For example, if we say on average a project will receive around 20 to 

30 change requests, consider how much time and effort goes into assessing the impact of change, approving/disapproving 
the change, if approved—the effort required to update the project documents and potentially rebasing the project. Again, 
some allowance should be made to cover the many project administrative process required by the organisation's PMO. 


This table provides an indication of how broadly as a project manager you have to consider the 


costs to the project. The table is by no means exhaustive and the project manager and project team 
should investigate further. 

Obviously from a direct-cost perspective (i.e. those costs directly attributable to the project) the 
WBS, work packages and the bill of materials (BoM) contribute a large amount of information into the 
construction of the project budget. 
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10.5 ESTIMATION OF COSTS 


Estimating is covered extensively in Chapter 8. The reader is encouraged to refer back to sections in 
Chapter 8 while studying this chapter. Estimating includes: 


m Estimating activity resources: This is the task of estimating the resources required by the project 
activities. Resources could be human or other (e.g. raw materials, facilities, plant and equipment) 
(PMI 2017). 


E Estimating activity durations: This is the task of estimating how long a resource is needed, in 
terms of a time period. For some resources, this could be measured in hours; for others, it could 
be weeks or months. The objective is to accurately identify how long each resource is required 
for, inclusive of factors such as lead-times, set-up times and teardown times. 


m Estimating activity costs: This task aims to accurately identify the costs associated with the 
resource for the required time period. The costs could be estimated using an overall figure or more 
likely indicate the cost for the resource (e.g. per hour, per day, per use or per weight) (PMI 2017). 


The whole process of estimating covers: 


‘what is required’ (e.g. skills, tools, equipment, raw material) 
for ‘how long’ (i.e. the duration of the ‘what’) 


‘when in the project timeline’ of events 


at ‘what cost’ to the project. 


At this point we should have identified and estimated all the costs relevant to the project or if taking 
a rolling-wave planning approach to the stage. The next key activity for the project manager is the 
preparation of the actual project budget. 


10.6 SIMPLE TIME-PHASED PROJECT BUDGETS 


Time-phased project budgeting is one of the simplest ways to arrange the costs of carrying out 
the project with the income (funding) of the project. On the construction of the timephased project 
budget the costs captured are what we refer to as planned costs—that is, they are the estimated costs 
that we plan to spend at a point in time on the project schedule. Inputs (as discussed in the previous 
two sections) include: 


all the clearly identified costs from estimating the WBS tasks and/or work packages 


Æ other holistic project costs that fall across the overall project that may not have been included 
within the tasks and/or work packages (e.g. the cost of the project manager, office space, 
telephone costs, ICT equipment and employment overheads) 


E the project bill of materials 


the project’s cash inflows (income) and the timing of these within the project budget. 


Without an accurate timephased project budget, it would not be possible to monitor actual costs spent 
against the planned costs, and report on the variance between the two. 


10.6.1 Simple time-phased project budget structure, by category 


The project budget is typically maintained within either a spreadsheet (for most small to medium 
sized projects) or (as outlined previously) in the organisation's finance and/or ERP systems. When 
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maintained in spreadsheets, project budgets are usually organised as simple expenditure and income, 
split along a timeframe. Taking the simple WBS introduced in Chapter 7, now drafted as a WBS (see 
Figure 10.3), the process of moving the relevantinformation into the time-phased budget. will be explained. 

Let’s now start to develop a time-phased project budget spreadsheet for the ‘foundations’ deliverable 
(refer Figure 10.3). It is important to note that the ‘time-phasing’ (i.e. at what time-point the costs 
fall), are known, as the project manager would have created the project schedule and would therefore 
know when a work package (or task) is scheduled to take place (remember the costs associated with 
that. work package would have been captured in the work package dictionary item). 

Referring to Figure 10.4, the reader will also be able to see that. the planned, actual, variance 
(PAV) approach has been taken to planning and subsequently tracking (controlling) costs in the project. 


E Planned: The baseline (estimated planned and subsequently approved) value for the stage of the 
project. In this case the ‘foundations’ deliverable was planned to be $48 560. 


@ Actual: The actual value charged to the project once the work has been completed. In this case 
the ‘foundations’ deliverable actually incurred costs of $27 3@@ (in January) plus $22 @6@ (in 
February) giving a total of $49 360. 


@ Variance: The Variance = Planned - Actual. A negative number indicates the actual spend is 
greater than was planned, and a positive number indicates the spend is under budget, that is, 
below what was planned. In the example the variance is the planned value of $48 56@ minus the 
actual value of $49 360, which equals —$800. So, at this point in time the project is $800 overspent. 
In the spreadsheet (see Figure 10.4) a ‘comments’ column can be used to capture the reason(s) 
why. This figure can then be reported on in the project status report and the reasons for the 
difference articulated. 


Figure 10.3 House build: work breakdown structure 
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Figure 10.4 
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Note: These time-phase project budgets are also known as the ‘project's cash flow statements’; much 
like a business’s cash flow, they show expenditure against income over a set period of time. 

The project manager's choice of categories in the ‘Expenditure’ column determines how the 
categories of costs are going to be tracked within the spreadsheet. In this example, categories for 
expenditure included the subcategories of ‘tools/equipment’, ‘materials’, ‘labour’ and ‘overheads’. The 
categories used in the example were selected because of their relevance to the project. Other options 
for categorisation of costs include: 


E Chart of accounts: The project manager may have to (mandatorily) use the chart of accounts 
issued by the organisation's finance department. 


E Project accounting codes: are a specific set of codes issued to the project manager to account 
for costs and revenue in the project—again, issued by the organisation's finance department and 
most probably mandatory. 


E Fixed direct/fixed indirect categories: Direct costs are those directly attributable to the project 
(e.g. concrete, purchase of IT equipment, hiring of staff). Indirect costs cannot be directly 
attributed to the project but usually occur as a result of a direct cost (e.g. superannuation 
payments for hired staff). 


E Variable direct/variable indirect: Variable costs change with the amount of some quantity being 
costed. ‘Variable direct’ could be costs of IT support-—every time the project calls the service desk 
they are charged for the call, but the final cost depends on how many calls are made. ‘Variable indirect’ 
could be a leave loading for hired staff, which is obviously affected by the amount of holiday taken! 


For any of the above, the codes/definitions would be captured in the Cost Management Plan, and 
communicated to all those involved so a consistent approach is taken to recording cost items against 
the correct code(s). 
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Within the ‘Income’ column (Figure 10.4), the ‘funding releases’ have been captured, based on the 
project manager’s planned estimates—you will also be able to see the basis of the estimates has been 
captured. 

Calculating down the columns enables the project manager to control variances along the time 
dimension. For example, in January the planned minus the actual equals —$800, so we can immediately 
see the project has overspent. 

Calculating along the rows would enable the project manager to calculate the total for each 
category and subcategory; for example, the total planned cost of the ‘general labourer #1’ 
comes in at $2000 (January) + $400 (February) = $2400 (total not shown in this excerpt of the 
spreadsheet). 

This enables the project manager to ask questions such as: 


m Have we overspent on a resource type? 

@ By how much? For what reason? 

@ Was the estimate carried out using incorrect information? 
@ Dothe estimating tools need to be updated? 


@ What lessons learned can be drawn? 


10.6.2 Simple time-phased project budget, by WBS 


Another variation of the time-phased project budget is to track costs by the contro] account, 
work package and/or task. Figure 10.5 provides an illustration. The project budget shown 
in Figure 10.5 is based on the house build WBS in Figure 10.3, in particular the ‘foundations’ 
deliverable. This method for developing the project budget provides a very detailed methodical 
approach to the preparation of the budget and allows for the tracking of planned, actual and 
variance details against each work package and across time. Note that the time dimension for 
both these examples has been defined as months; however, on shorter, fast-paced projects, the 
project manager may select a more frequent time dimension such as weeks or, in some cases, 
days! The disadvantage of tracking by WBS is that the project budget can become very large; 
the advantage is that it tracks the timeline of the project schedule—and indeed some project 
managers take the cost information and track from within a software scheduling package such 
as Microsoft® Project. Microsoft Project allows for the costs against each work package to be 
entered directly into the tool. 

In both examples, the transfer of costs to the month in which they occurred has been sourced 
from either the project network (e.g. activity-on-node (AON) diagram) or, more commonly, from the 
project's Gantt chart (project schedule). 

Whichever style of project budget is developed, it can be expanded to record and track a host 
of other financial-related information. There is value in doing so to allow more complete analysis 
for both performance reporting and lessonslearned analysis. For example, in Figures 10.4 and 10.5, 
additional columns could be inserted to track: 


@ estimating information, including: 
— estimate value/s 
— source of the estimate 
— estimate method (e.g. PERT) 


— estimate expiration (most quotes are only valid for a limited time) 
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Figure 10.5 Time-phased project budget, by WBS/work package 
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m invoice information, including: 

— invoice number/s 

— dates issue/paid 

— supplier name 

— schedules of payments 

— notes on supplier performance 

— references to contract terms and conditions 
@ quality criteria 

— quality assurance criteria that must be met before payment 
m tracking information, including: 

— tracking totals—plaimed actual and variance—by month and to date 


— earned value information (refer to Chapter 11). 


Note: The sum of the planned values, totalled by month, and then all the months totalled together 
would equate to the planned value (PV) for the project. This PV for the entire project is typically set 
on approval after the Planning stage of the project, before the project moves into the Executing stage. 
The figure is known as the cost baseline for the project. Any changes to cost would result in change 
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requests being raised, and would be assessed from this cost baseline (in conjunction with the other 
two baselines—the scope baseline and the schedule baseline). 


10.6.3 Simple time-phased project budget, by WBS and OBS 


The third type of perspective of the timephased project budget is to take the timephased project 
budget by WBS and layer onto the budget the organisational breakdown structure (OBS), this enables 
the project manager to see where the costs fall by department in the organisation. Not all projects will 
require this view of the budget, but it has been included to illustrate how different presentations of the 
projects budget can assist the project manager in communicating different perspectives of the cost 
component of the project to the different stakeholders. Refer Figure 10.6. 

In Figure 10.6, it is possible to see the impact from a cost perspective against each of the 
departments’ functions. This has additionally been split into three total lines to capture ‘planned 
labour costs’, ‘planned equipment costs’ and ‘planned material costs’. The project manager could use 
this information, for instance, to have discussions with the department. managers. 


10.7 PROJECT COST CONTROL AND MONITORING 


Many things can go wrong during the Executing stage; these are wide-ranging and varied but some 
common issues can arise from: 


m Costs increase from the time of the estimate to the time the project enters the Executing phase— 
for example, there is an increase in labour charges, which cannot be accommodated by the 
organisation that quoted the original costs. This is especially prevalent in the construction/mining 
industry with the ebb and flow of large (multi-billion dollar) projects. 


@ The time it actually took to complete an activity (work package) blows out, thereby increasing costs. 


@ Unplanned findings occur during an activity (work package), which were not planned for in the 
original estimate—this is especially true in construction projects once the first hole is dug and 
a water pipe or communications cable is suddenly discovered that was not on the plans of any 
council or utility company! 


@ Natural forces change the market conditions—for example, when Cyclone Yasi hit Northern 
Queensland in 2011, many utility and infrastructure companies had to redeploy resources to 
emergency projects, taking away from planned project activity. 


What can the project manager do in such cases? Refer to Chapter 7, where the change control process 
was introduced. In any case, where there has been a cost overrun (for any reason), the project 
manager (or requestor of the change) should raise a change request and seek appropriate approvals 
(at the timepoint the event occurred preferably). The cost increases are subject to an analysis of the 
impact to the project and the triple constraints—scope (performance), cost and time. The outcome of 
the change analysis might be to accept the change, approve an increase to the budget or pull funds 
from the contingency set aside for the project. 

The key to cost control is to monitor closely the spend that is taking place and, using simple tools 
such as a project spreadsheet (or reports from the company’s ERP/financial system), monitor costs 
against what was planned (estimated) to be spent and what was actually spent. 

Various charts can be plotted using such time-phased information, such as a simple graph of 
planned spend and actual spend. See Figure 10.7, which relates to the progress of the house build 
project, and plots the data on cumulative planned costs and cumulative actual costs. 

Simple charts such as this (and others as illustrated in Chapter 12), to control the quality of the 
project, can be quite effective. Further information and discussion on project performance reporting 
is contained in Chapter 11, including a detailed discussion on the earned value management (EVM) 
approach to reporting cost and schedule dynamics. 


Figure 10.6 Time 
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In all stages of the project, but especially in the Executing stage, the project manager is 
accountable for tracking this information and taking pre-emptive actions based on the data. 


The tracking of actual costs against those planned (and 
project manager during the monitoring and controlling 


approved) is a critical activity of the 
of a project. 


In addition to tracking the planned against the actual, the project manager can use more-advanced 


techniques such as the calculations of EVM to forecast out the planned value for the project at 
completion in addition to schedule related metrics (refer Chapter 11). 

In monitoring and controlling the project budget, one of the project manager's biggest headaches 
can be in reconciling the costs actually incurred, when they occurred and matching to this to the 


SNAPSHOT FROM PRACTICE Project accounting guidelines 





While jointly managing a PMO for a large energy distribution 
company in Australia, one of the authors (Pearson) was 
involved in establishing governance, processes, policies and 
templates for the business change, project management 
framework (PMF). Among the various policies developed 
was a policy related to capitalisation of assets. 


When the value of money leaves a company, the 
company reports it as an expense. Expenses 
reduce profit. Every $1 in wages that you pay a 
teenager who staffs your ice cream stane is $1 that 
leaves your company, so it reduces your profit by 
$1. But the value of money spent on assets doesn’t 
leave the company, so it’s not recorde@ as an 
expense ane therefore doesn't reduce profit. The 
value remains on the balance sheet. This is asset 
capitalization (Merritt n.e.) 


So, by capitalising assets correctly, such as a $20 000 
ice cream maker for the business mentione@ above, an 
organisation can gain by a depreciation of the assets over 


the life of the asset, as the ice cream maker will not be 
worth $20 000 in, say, five years’ time. 

The principle can be applied in most countries, 
according to the local tax laws. As the energy distributor 
was an Australian Government-owned corporation, codes 
of accounting practices related to government were 
applicable. Sourcing information on asset capitalisation 
ane depreciation of software assets, the author discovered 
a different set of guidelines, as documented in Accounting 
Guidance Note No. 2007/1—Accounting for Internally 
Developed Software (Australian Government 2007). 
Armed with this information, the author was able to capture 
the essence of the accounting guidance note, ane include 
instructions for project managers on what coule/could not 
be capitalised within the relevant section of the PMF. 


Sources: Merritt C n.d., ‘What does capitalizing assets mean?’, Chron, http// 
smallbusiness.chron.com/capitalizing-assets-mean-65016.html); Australian 
Government. Accounting Guidance Note No, 2007/1-Accounting for 
Internally Developed Software, Department of Finance an@ Deregulation, 
https://www.finance.gov.u/publications/accounting-guidance-notes/docs/ 
AGN_2007-1-Internally-Developes-SoNware paif), accessed February 2018 
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company's accounting practices of issuing and paying invoices. A tip here is to diligently stick with 
the project schedule and the project budget—for example, when a work package is completed and 
the monies allocated spent, this is what gets recorded in the project budget; do not, for instance, delay 
accounting for the money until the invoice has been paid by the finance department. This is because 
there could be substantial time differences between the two events occurring, and trying to reconcile 
can otherwise become an endless administrative task. The KISS (Keep It Simple Stupid) principle 
definitely applies here: when the work package is complete (at its allocated timepoint), the money 
has effectively been spent and should be recorded as such in the project budget. 

The Snapshot from Practice: Project accounting guidelines illustrates how project environments 
must support the business in all senses of the word. It also illustrates the value as a project manager 
in consulting with your PMO, or the Finance Department, to capture any such financial governance 
(early on in the project), within the project’s Cost Management Plan. 


10.7.1 Contingency planning 


We stated earlier in the chapter that contingency is an amount of funds allocated for events that are 
outside the approved project budget. There are a number of questions to be answered when allocating 
contingency funds: 


m How much should be allocated for contingency? 
m How does the project manager / the project gain access to the funds? 


m What approvals need to take place? 


In practice, contingency funds are usually retained by the PMO or project sponsor or project steering 
committee. Access to these contingency funds is via the change request process (outlined in Chapter 7). 
Industry thinking on contingency amounts often makes reference to risk. Lowrisk projects typically 
hold back around 10 per cent of the total planned project budget in a contingency fund, with amounts 
of 30 per cent held back for highrisk projects. In practice, the amount of contingency held back is 
often a reflection of the resulting risk analysis and funds required for identified risk mitigation and 
contingency planning. (Refer to Chapter 17 for further details.) 

The PMI illustrates the contingency amounts as indicated in Figure 10.8. This figure has been 
annotated to assist the reader in interpreting how the contingency amount is arrived at, reading from 
left-to-right across the figure. 

In essence, there are therefore two types of reserves: 


1. Project reserves, accounted for with the activity and work packages: 


— They are under the control of the project manager and are subject to the integrated change control 
process. 


— They are used to deal with known-unknowns. 


— They are included in the cost baseline. 


2. Management reserves, accounted for as a specified amount on the summation of the control 
accounts: 


— They are subject to the integrated change control process (and therefore) management 
approval. 


— They are used to manage unknown-unknowns. 


— They are included in the project budget. 





(PMI 2017) 
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Figure 10.8 P 
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Source: Adapted from the Project Management Institute (PMI) 2017, A Guide to the Project Management Body of Knowledge, 
6th edn, PMI, p.255 


After approval of a change request to gain access to reserves, including documenting why the funds 
are needed, the project budget would be increased by the agreed amount, which would also result in 
an increase to the project’s cost baseline (and therefore a subsequent cost baseline would be issued 
and worked against from that point in time). Some project managers actually track the amounts 
of contingency calculated at each of the levels indicated in Figure 10.8, to ensure that contingency 
reserves are not being depleted too quickly, too early on in the project—a sure sign that the project 
may be heading for disaster. An example of a simple chart is indicated in Figure 10.9. 


10.7.2 Project heath checks and audits 


Project budgets and adherence to the governance captured in the Cost Management Plan, and 
associated financial policies and procedures, are often targets (along with project procurement 
management) for internal health checks or more stringent external audits. The project manager 
must have confidence in the transparent manner in which the project budget was initially created and 
in the subsequent monitoring and controlling of the project budget, change request process adherence, 
and appropriate access to contingency funds. 


10.8 COST CLOSURE 


Although there is no formal cost closure in the project cost management knowledge area, the PMI 
does cover costs to a limited extent in the ‘Project closure’ section of PMBOK (PMI 2017). This text 
takes asimilar approach, and in Chapter 19 project cost closure is considered. For completeness of the 
present chapter, some project cost closure activities are captured below: 


m Final project reporting (baseline versus actual budget)and updating the organisation's corporate 
systems with final project costs. It is important to ensure that the final situation is represented 
in corporate systems; this could include the final reconciliation of invoices, paying invoices and 
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Figure 10.9 Contingency tracking 
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capturing outstanding invoices. Outstanding invoices (and approval to pay) would be handed 
over to the organisation's finance department. 


@ Running any final financial reports from financial systems and including as annexes to the 
project’s final status report or post-implementation review (PIR) report. 


@ Closing down logical access to systems and project accounts. This is to prevent any future 
projects from booking costs to the account codes setup for this project. The author has 
experienced unscrupulous project managers booking costs to a ‘balanced and closed’ projects 
account codes to hide overruns in costs on their projects. 


Em Capture of costrelated lessonslearned—whether these are related to the processes that drove 
cost management in the project or from the actual estimating activities and cost changes/issues 
encountered during the delivery of the project. 


m Providing a final statement of the project budget, increases/decreases logged as a result of 
change requests, and a final balance of the project and narrative as to whether the project was 
within budget or overrun. 


m Ensuring capitalisation and depreciation of assets and any other relevant financial guidelines 
have been applied according to the letter of the law. 
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10.8.1 Premature project closure 


If a project is prematurely closed (for whatever reason) the project manager would carry out a full 
project closure including all the costrelated activities. Remember, sunk cost is a loss that should not 
play any part in determining the continuation of the project. The project manager, steering committee 
and management team must declare the sunk costs of the project and move forward. 


10.9 SCRUM/AGILE CONSIDERATIONS 


There is currently a lot of discussion on how to successfully cost a Scrum (Agile) project. Drawing from 
the general Scrum community (refer to the weblinks at the end of the chapter) and personal author 
experiences, below are a number of suggestions that may assist with costing in aScrun/Agile environment. 


m Costing suggestion 1: One chain of thought is, because we know what resources will be required 
post the sprint planning meeting, we can then put a pretty accurate estimate on what that sprint. 
will cost the business. These costs, along with the sprint backlog, can be presented to the product 
owner, who can make a judgement call on whether they wish to progress with the value being 
delivered for the cost provided. 


E Costing suggestion 2: Asa Scrum team (product owner, Scrum master and the make-up of the 
development team) is meant (designed) to be relatively static for the duration of the project, we 
should therefore know the costs of each of these ‘resources’ and be able to place a repeatable cost 
on any sprint. 


@ Costing suggestion 3: In Chapter 9, the concept of building an epic, increment, sprint (and task) 
level project schedule was floated. If this was achieved, then the product owner in conjunction 
with the Scrum master should be able to place an estimate of the costs. This could range in 
accuracy from a rough order of magnitude (ROM) estimate to something quite accurate. 


E Costing suggestion 4: Move the business to understand an incremental model of funding 
generally—that is, as part of introducing the Scrum approach, also introduce the company to the 
incremental approach to funding (e.g. taking Costing suggestion 1 and 2). 


E Costing suggestion 5: Referring to Chapter 18, if the work is to be outsourced and is of a Scrum 
(Agile) nature, considerations in how to set up the contract should be taken carefully. 


Project cost management requires a lot of attention to detail. Project cost management takes various inputs from 
the project schedule management (such as the WBS, work package dictionary items, and the baseline schedule). 
Leveraging these artefacts and other estimating information enables the project manager to form an accurate project 
budget, subsequently baselined in order to monitor and control costs. This chapter has considered the following: 


m Project cost management has its origins in the development of the project scope document, including the WBS 

and the accurate estimation of resources, material, plant and materials. The estimates provide information for 

durations and unit costs, which in turn provide the basis of costing the project. 

m From this information (above) the subsequent development of the time-phased project budget can take place. 

m The Cost Management Plan governs and captures business rules around how costs are managed and reported in 

the project, along with other items such as policy and procedure, contingency, estimating, use of corporate systems, 

ong lead-time and large capital items, funding sources and lessons-learned. 

m The cost baseline (planned value) represents the sum of the cost accounts (if used, or deliverables) and the sum of 
the work packages below. Remember, if your budgeted costs are not time-phased, you really have no reliable way to 
measure performance—when monies were planned to be spent and what was actually spent. 
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The project manager is accountable for monitoring and controlling costs throughout the life cycle of the project. This 
includes the financial viability of the project, ensuring that there is sufficient funding to cover the outgoings of the 
project. The project manager must also report on costs as a part of the project's status report, as documented in the 
Cost Management Plan. 


https://www.scrum.org 

https://scrumology.com 

https://products.office.com/en-gb/project/pro ject-and-portfolio-management-software?tab=tabs-1 
https://www.ecosys.net/solutions/pro ject-cost-management/ 

www.costmanagement.eu 

https://www.aconex.com/project-cost-management-software 
https://www.oracle.com/uk/applications/primavera/products/pro ject-management.html 


audits direct/indirect costs make or buy analysis 

baseline finance/ERP systems planned, actual, variance approach 
chart of accounts fixed/variable costs (PAV) 

contingency health checks project accounting codes 

cost baseline large capital items sunk costs 

critical path long lead-time items time-phased project budgeting 


Review questions 


4. What types of project cost structures can be established? How do you track project costs in your project environment? 

2. Why is it important to establish links with the finance department of the organisation when drafting the Cost 
Management Plan? 

3. What is the purpose of ‘contingency’ and how can access be gained to contingency funds? 

4. What systems does your organisation use to track project budgets, and whose responsibility is it to ensure that 
appropriate access is maintained to these systems? 

5. What is the significance of identifying long leadtime items and large capital items early on in the project life cycle? 

6. What is the project ‘cost baseline’ and how is it arrived at? 

7. When should the change/variation process be invoked from a cost control perspective? 

8. What additional information can be gained from simple spreadsheet budgets to monitor and contro! project costs? 


Remember the ‘planned’ and ‘actual’, and tallies across the rows. 


1. (a) Develop a spreadsheet template that represents the manner in which costs are accounted for in your organisation. 


(b) Modify this template to include the WBS and/or OBS overlays. Comment on what additional ‘control information this 
would now provide to you as a project manager. 


2. Develop a Cost Management Plan using the headings indicated in this chapter, and any additional headings your 
organisation uses. 
3. Review recent project management press articles and identify six lessons-learned from the articles. Reflecting on these 


lessons-learned, suggest ways in which these can be leveraged (for positive lessons) or avoided (for negative lessons) in 
a project you have worked on. 
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CHAPTER 11 


PROGRESS AND PERFORMANCE 
MEASUREMENTS 





Learning elements 


44 Understand the importance of project performance reporting and the typical types 
of project reports produced. 


4418 Understand the importance of being able to accurately report on the current status 
and forecast the performance of a project. 


44C Be able to apply the earned value management (EVM) technique to project 
performance reporting. 








In this chapter 


Æ 11.1 Introduction 
Æ 11.2 Structure of a project monitoring system 
11.3 Controlling project costs, resources and schedules 


11.4 Monitoring time performance 


11.6 Developing a status report: A hypothetical example 





E 
Æ 11.5 Developing an earned value (EV) cost/schedule system 
E 
E 


11.7 Earned value management (EVM) indexes to monitor progress 
| 11.8 Forecasting final project cost 
Æ 11.9 Other control issues 


m 11.10 Further project performance considerations 





m= Summary 
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11.1 INTRODUCTION 


Evaluation and control are part of every project manager’s job; control by being on the ground 
and/or personal involvement can overcome most problems in small projects. But large projects 
need some form of formal control. Control holds people accountable, prevents small problems from 
mushrooming into large problems and keeps focus. Except for accounting controls, project control is 
not performed well in most organisations. 

Control is one of the most neglected areas of project management. Unfortunately, it is not 
uncommon to find resistance to control processes. In essence, those who minimise the importance 
of control are passing up a great opportunity to be effective managers and, perhaps, allow the 
organisation to gain a competitive edge. Neglecting control in organisations with multiple projects 
is even more serious. For effective control, the project manager needs a single information system to 
collect data and report progress on cost, schedule and specifications. The general structure of such a 
system is discussed next; note, however, in relation to the project life cycle introduced in Chapter 2, 
the material discussed in this chapter falls within the ‘monitor and control’ process. The chapter also 
brings together some of the integrative aspects of cost, time and resources management. 


11.2 STRUCTURE OF A PROJECT 
MONITORING SYSTEM 


A project monitoring system involves determining whet data to collect; how, when and who will collect 
the data; analysis of the data; and reporting current progress. 


11.2.1 What data is collected? 


Data collected is determined by which metrics will be used for project control. Typical key data 
collected includes actual activity duration times, resource usage and rates, and actual costs, which 
are compared against planned times, resources and budgets. Since a major portion of the monitoring 
system focuses on cost/schedule concerns, it is crucial to provide the project manager and stakeholders 
with information to answer questions such as: 


What is the current status of the project in terms of schedule and cost? 
How much will it cost to complete the project? 

When will the project be completed? 

Are there issues that need to be addressed? 

What, who and where are the causes for cost or schedule overruns? 


What did we get for the dollars spent? 


If there is a cost overrun midway in the project, can we forecast the overrun at completion? 


The performance metrics you need to collect should help to answer these basic questions. Examples 
of specific metrics and tools for collecting data will be discussed in detail later in this chapter. 


11.2.2 Collecting data and analysis 


With the determination of what data is collected, the next step is to establish by whom, when and how 
the data will be assembled. Will the data be collected by the project team, contractor or project manager? 
Or will the data be derived electronically from some form of surrogate data such as cash flow, machine 
hours, labour hours or materials in place? Should the reporting period be one day, one week, one month or 
other? Is there a central repository for the data collected and is someone responsible for its dissemination? 
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Electronic means of collecting cost, time and resource data have vastly improved data collection, 
analysis and dissemination. For example, numerous software vendors have programs and tools to 
analyse your collected data and present it in a form that facilitates monitoring the project, identifying 
sources of problems and updating the project schedule and budgets. 


11.2.3 Reports and reporting 


First, who gets the progress reports? We have already suggested that different stakeholders and levels 
of management need different kinds of project information. Senior management's major interests are 
usually, ‘Are we on time and within budget? If not, what corrective action is taking place?’ Likewise, 
an ICT manager working on the project is concerned primarily about their deliverable and specific 
work packages. The reports should be designed for the right audience. 

Typically, project progress reports are designed and communicated in written and/or oral form. A 
common topic format for project progress reports is shown below: 


@ executive summary/narrative 
@ progress since the last report 
@ current status of project 
— schedule (time) 
— cost. 
— scope 
@ cumulative trends 
@ escalations and issues since the last report 
— actions and resolution of earlier problems 
— new changes/change requests and plans accepted into the project (or rejected) 


@ risk profile of the project and details of any issues and plans invoked to handle risks. 


11.2.4 Communications Management Plan 


Project reporting requirements are usually defined within the project Communications Management 
Plan—as discussed in Chapter 16. The project Communications Management Plan, supported by the 
Communications Matrix, captures details of all project communications including the schedule and 
type of project reporting. 

Typically, the project manager will identify and capture the required information on project control 
reports—in terms of who they are sent to, at what time and a sample of the report template—within the 
Communications Management Plan. A hint from practice would be for the project manager to also include 
a task (or milestone) on the project schedule to indicate the effort required and due dates of these reports. 


11.2.5 Types of reports 


Most project managers will become familiar with two key types of project reports: full reporting 
and exception reporting. As the name suggests, full reporting provides a comprehensive report 
on all dynamics of the project, usually in considerable detail, covering the areas of scope, schedule, 
cost, quality, resources, communications, risk, stakeholders (including organisational change) and 
procurement. A typical full report may include information such as: 


E an executive summary 


@ cost analysis 
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schedule (time) analysis, including milestones/deliverables summaries 
previous week, current week, next week tasks and supporting narrative 
risk profiles, including details of changed risks 

issues raised (as a result of risks turning into issues) or other project issues 
outstanding project changes requests, their status and impact analysis 
validation of scope and/or Business Case to ensure validity of the project 
resource utilisation in the previous week, current week, next week format 


quality nonconformances 


contract status and performance tracking. 


The other key type of report which is often popular with project managers and executives alike 
is the exception report. Here, only exceptions from the agreed baselines (scope, time, cost) are 
highlighted with plans for rectifications presented. Table 11.1 indicates some of the advantages and 
disadvantages of each type of report. 

How the project report is delivered may also vary from organisation to organisation. Most project 
managers will be familiar with documenting the project in a written report format and sending this 
(usually via email) to executive management, the project steering committee and/or the project 
management office (PMO). After delivery of the report, there could typically be a feedback and/or 
questions loop, where the project manager responds to questions. 


Table 11.1 Key reporting types: advantages and disadvantages 





Full reporting Exception reporting 

Advantages Advantages 

m Covers all of the major project dimensions in m Focuses executive management's attention on changes 
comprehensive detail. to the agreed/approved baseline plan (not the entire 


status of all aspects of the project). 
m More efficient for project managers and the project team 
to prepare (less time-consuming). 


Disadvantages Disadvantages 


m Can consume alot of project management time to m Presents only exceptions (so achievements may be 
generate. underplayed). 

m Can result in executive management information m Executive management has to request details / may be 
overload. unaware of original/re-baselined data and information. 


m Does not focus executive management's attention 
on the ‘exceptions’ or issues that need attending to. 


Some organisations provide a forum, such as a project review meeting (or steering committee 
meeting) with key stakeholders, where the project manager will be asked to deliver the report and 
verbally make a summary and field questions. The project manager must be prepared to answer on- 
the-fly, on-the-spot questions with this face-to-face approach as the discussion progresses. 

Remember, the organisation’s PMO or project steering committee will influence the format and 
delivery style of the project status report; their engagement early on in the project will ensure these 
groups of stakeholders are kept informed, as the project progresses, in the format they require 
and specify. The remainder of this chapter discusses other types of project information that may 
be included in the project status report, or used by the project manager for project control and 
monitoring. 
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11.3 CONTROLLING PROJECT COSTS, RESOURCES 
AND SCHEDULES 


‘Control’ is the process of comparing actual performance against plan to identify deviations, evaluate 
possible alternative courses of actions, and take appropriate corrective action. The project control 
steps for measuring and evaluating project performance are presented below: 


Step 1 Setting a baseline. 

Step 2 Measuring progress and performance. 
Step 3 Comparing plan against actual. 

Step 4 Taking action. 


Each of the control steps is described in the following paragraphs. 


11.3.1 Step 1: Setting a baseline plan 


The baseline plan provides us elements for measuring performance. The baseline is derived from the 
cost and duration information found in the work breakdown structure (WBS) and time-sequence data 
from the network and resource scheduling decisions. From the WBS, the project resource schedule is 
used to time-phase all work, resources and budgets into a baseline plan (see Chapter 9 and Chapter 16). 
The baseline Project Management Plan (PMP), and all its subcomponents such as the project schedule 
and project budget, are then typically approved at a gateway review between the Planning stage and 
Executing stage of the project life cycle. This approved PMP is often referred to as the baseline plan, 
and it is from this baseline PMP that subsequent monitoring and controlling of the various parameters 
of the project takes place. Remember, the three specific baselines within the baseline PMP are the 
scope baseline, cost baseline and schedule baseline. 


11.3.2 Step 2: Measuring progress and performance 


Time and budgets are quantitative measures of performance that readily fit into the integrated information 
system. Qualitative measures such as meeting customer technical specifications and product function 
are most frequently determined by onsite inspection or actual use. This chapter is limited to quantitative 
measures of time and budget. Measurement of time performance is relatively easy and obvious. That 
is: is the critical path early, on schedule or late? Is the slack of nearcritical paths decreasing to cause 
new critical activities? Measuring performance against budget (e.g. money, units in place, labour hours) 
is more difficult and is not simply a case of comparing actual versus budget. Earned value (EV) is 
necessary to provide a realistic estimate of performance against a timephased budget. EV is defined as 
the budgeted cost of the work performed. This is reviewed in detail later in this chapter. 


11.3.3 Step 3: Comparing plan against actual 


Because plans seldom materialise as expected, it becomes imperative to measure deviations from 
the plan to determine if action is necessary. Periodic monitoring and measuring the status of the 
project allows for comparisons of planned versus actual (tracking) information on the project. It is 
crucial that the timing of status reports be frequent enough to allow for early detection of variations 
from plan and early correction of causes. Usually status reports should take place every one to four 
weeks to be useful and allow for proactive correction. The timing of these reports will be determined 
by the type of project; for example, short projects of less than three months may require weekly 
project reporting, while longer, more complex projects may be reported on a monthly basis. 


11.3.4 Step 4: Taking action 


If deviations from plans are significant, corrective action will be needed to bring the project back in 
line with the original or revised plan. In some cases, conditions or scope can change, which, in turn, 
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will require a change in the baseline plan to recognise new information. The change request process 
introduced in Chapter 7 would provide the governance around which changes are accepted into the 
project, and which are not. 

The remainder of this chapter describes and illustrates monitoring systems, tools and components 
to support managing and controlling projects. Several of the tools you developed in the planning and 
scheduling chapters now serve as input to your information system for monitoring performance. 
Monitoring time performance is discussed first, followed by cost performance. 


11.4 MONITORING TIME PERFORMANCE 


A major goal of progress reporting is to catch any negative variances from plan as early as possible 
to determine if corrective action is necessary. Fortunately, monitoring schedule performance is 
relatively easy. The project network schedule, derived from the WBS or organisation breakdown 
structure (OBS), serves as the baseline to compare against actual performance. 

Gantt charts (bar charts) and control charts are the typical tools used for communicating 
project schedule status. As suggested in Chapter 9, the Gantt chart is the most favoured, used and 
understandable. This kind of chart is commonly referred to as a tracking Gantt chart. Gantt 
and control charts serve well as a means for tracking and trending schedule performance. Their 
easy-to-understand visual formats make them preferred tools for communicating project schedule 
status—especially to top management, which does not usually have time for details. Adding actual 
and revised time estimates to the Gantt chart gives a quick overview of project status on the 
report date. 


11.4.1 Tracking Gantt chart 


Figure 11.1 presents a baseline Gantt chart and a tracking Gantt chart for a project at the end of 
period 6. The solid bar below the original schedule bar represents the actual start and finish times 
for completed activities or any portion of an activity completed (see Activities A, B, C, D and E). For 
example, the actual start time for Activity C is period 2; the actual finish time is period 5; the actual 
duration is three-time units, rather than four scheduled time periods. Activities in process show the 
actual start time, and the extended bar represents the expected remaining duration (see Activities 
D and E). The remaining duration for Activities D and E are shown with the hatched bar. Activity F, 
which has not started, shows a revised estimated actual start (9) and finish time (18). 

Note how activities can have durations that differ from the original schedule, as in Activities C, 
D and E. Either the activity is complete and the actual is known, or new information suggests the 
estimate of time be revised and reflected in the status report. Activity D's revised duration results 
in an expected delay in the start of Activity F. The project is now estimated to be completed one 
period later than planned. Schedules represented as Gantt charts have multiple uses; for example, task 
and subtasks can be rolled up into ‘summary’ activities for management reporting, the relationships 
between activities can be made visible for product and team level discussions, and resources and 
percentage complete can be displayed against each subtask. 


11.4.2 Control chart 


This chart is another tool used to monitor past project schedule performance and current performance 
and to estimate future schedule trends. Figure 11.2 depicts a project schedule control chart. The chart 
is used to plot the difference between the scheduled time on the critical path at the report date with 
the actual point on the critical path. Although Figure 11.2 shows the project was behind early in the 
project, the plot suggests corrective action brought the project back on track. If the trend is sustained, 
the project will come in ahead of schedule. Because the activity scheduled times represent. average 
durations, four observations trending in one direction indicate there is a very high probability that there 
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SNAPSHOT FROM PRACTICE Status reports at Microsoft 





When Bill Gates was in charge of Microsoft, major project 
teams sentreports each month to top executives, as well as 
to the managers of all related projects. The status reports 
were brief and hae a standard format. Gates read most 
of them quickly ane spotted potential delays or changes 
he die not want. He especially looked for schedule slips, 
cutting too many product features or the need to change 
a specification. Gates usually responded to the relevant 
managers or developers directly by email. Status reports 
are an important mechanism for communicating between 
top management and projects. As Gates explained: 

‘| get all the status reports. Right now there might be 
a hundred active projects . . . [The status reports] contain 


in spec, aned any comments about “Hey, we can’t hire 
enough people,” or “Jeez, if this OLE (Object Linking ane 
Embedding) 2 Mac release isn't done, we're just going 
to have to totally slip”... They know [their report] goes 
up to all the people who manage all the other groups 
that they have dependencies with. So if they don't raise 
it in the status report ane then two months later they say 
something, that’s a breakdown in communication ... The 
internal group is totally copied on those things, so it’s 
sort of the consensus of the group.’ 


Source: Cusumano MA & Selby RW 1995, Microsoft Secrets: Haw the 
World's Most Powerful Software Company Creates Technelegy, Shapes 
Markets and Manages People. Simon & Schuster. New York. 


the schedule, including milestones dates, ane any change 


is an identifiable cause. The cause should be located and action taken if necessary. Control chart trends 
are very useful for giving warning of potential problems so appropriate action can be taken if necessary. 

Control charts are also frequently used to monitor progress towards milestones, which mark 
events and as such have zero duration. Milestones are significant project events that mark major 
accomplishments. To be effective, milestones need to be concrete, specific, measurable events. Milestones 
must be easily identifiable by all project stakeholders—for example, ‘product testing complete’. The 
project manager would have set out and agreed on the project milestones as a part of scoping the project 
(as discussed in Chapter 7), and further refined these during the Planning stage of the project. Critical 
merge activities are good candidates for milestones. Control charts very similar to the example shown in 
Figure 11.2 are often used to record and communicate project progress towards a milestone. 

Schedule slippage of one day seldom receives a great deal of attention. However, one day here and 
another there soon add up to large delay problems. Research shows that once work gets behind, it has 
a tendency to stay behind because it is difficult to make up. Examples of causes of schedule slippage 
are unreliable time estimates, minor redesign, scope creep and unavailable resources. Using slack 
early in a schedule may create a problem for someone responsible for a later activity; flexibility and 
potential opportunities are therefore reduced. For these reasons, having frequent and clearly defined 
monitoring points for work packages can significantly improve the chances of catching schedule 
slippage early. Early detection reduces the chance of small delays growing to large ones and thereby 
reducing opportunities for corrective action to get back on schedule. See Snapshot from Practice: 
Status reports at Microsoft. 


11.5 DEVELOPING AN EARNED VALUE (EV) COST/ 
SCHEDULE SYSTEM 


EV is not new; although its initial use was in military contracts, in recent. years the private sector has 
come to depend on the system for managing complex and large projects. 

The original EV cost/schedule system was pioneered by the US Department of Defense in the 
1960s. It is probably safe to say project managers in every major country are using some form of 
the system. The system is being used on internal projects in the manufacturing, pharmaceutical 
and hightech industries. For example, organisations such as various Australian government 
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departments, NASA, Levi Strauss and Disney have used EV systems to track projects. The basic 
framework of the EV system, commonly referred to as ‘earned value management’ or more simply 
EVM, is withstanding the test of time. Most highend project management software includes EVM 
reporting; many systems have added industryspecific variations to more precisely track progress 
and costs. EVM techniques are captured in many books and standards, including the Australian 
Standard AS 4817-2006 (R2016). 

The Project Management Institute (PMI) considers EVM such an important aspect of the control 
of projects that it published the Practice Standard for Earned Value Management (PMI 2011). The 
PMI’s Guide to the Project Management Body of Knowledge (or PMBOK) (PMI 2017) also covers 
the basics of EVM. EVM is also known as ‘earned value analysis’ (EVA), indicating the nature of the 
technique—analysis. 

The EV system starts with the timephased costs that provide the project budget baseline, which is 
called the ‘planned budgeted value of the work scheduled’ (or ‘planned value’ (PV)) or, more simply 
put, the planned budgeted (and approved) project total cost (cost baseline at the start of the Executing 
stage). Given this time-phased baseline, comparisons are made with actual and planned schedule and 
costs using EV. The EV approach provides the missing links not found in conventional cost-budget 
systems. EVM aims to answer the following questions: 


Are we on schedule? 
Are we on cost? 


Do the costs incurred reflect the true accomplishments? 


What are the project's variances? 


The EV cost/schedule system uses several acronyms and equations for analysis. Table 11.2 
presents commonly used terms. To the uninitiated, the terms used in practice appear intimidating. 
However, once a few basic terms are understood and a few examples practised, the practitioner will 
soon become accustomed to applying the technique. To this aim, a ‘mini’ project example has been 
appended to the table, with the remainder of this chapter taking more complex project examples 
forward. 

Note: The table has been extended to include the ‘new’ metric around earned schedule (ES)—the 
rows shaded dark grey—as recent research has shown that ‘schedule variance’ (SV) and ‘schedule 
performance index’ (SPI) behave erratically for projects that are behind schedule and/or are nearing 
the end of the project. The reader is encouraged to read further into this topic at: http://www. 
earnedschedule.com. 


Table 11.2 Earned value management (EVM) terms, definitions and simple example 


Abbreviation | Name Calculation or value How to interpret | Example 


PV Planned value PV = planned value of the The ‘planned value’ ofthe workto Facilities have a short project for 
task or work package be completed. a contractor to paint four walls of 
Initial PV = approved The baseline at the start ofthe a large meeting room. 
estimate project Execution stage. Each wall has a (baseline-cost) 


PV of $250/wall. 

Each wall has a (baseline- 
duration) estimated at one-day 
effort to prepare and paint. 


AC Actual cost AC = actual cost of the The sum ofthe costs incurred in At the end of day two we receive 
work completed accomplishing work. a report from the site supervisor 
that informs us that three walls 
have been painted at a cost of 
$400. 
AC = $400 {for three walls) 


Continued 


Continued 
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Abbreviation | Name | Calculation or value How to interpret Example 


BAC 


cv 


CPI 


SV 


SPI 


SV\(t) 


Earned value 


Budget at completion 


Cost variance 


Cost Performance 
Index 


Schedule variance 


Schedule 
Performance Index 


Schedule variance (t) 


For each task (or, if tracked 
at the work package level, 
the work package). This is 
the ‘budgeted cost of the 
work performed’. 


BAC = planned value of the 
entire project 


cv =EV—AC 
CPI = EV/AC 
SV =EV — PV 
SPI = EV / PV 
Sv(t) = ES — AT 


The measure of work performed, 
expressed as the budgeted 
(planned) amount for the work 
performed. 


Initial BAC is the cost baseline for 
the entire project. 


<0 Over budget (over planned 
costs) 

=0 On budget 

>0 Under budget (under planned 
costs) 


A measure of the cost efficiency of 
budgeted resources. Expressed as 
the ratio of EV toAC. 

<1 Over budget 

=1 On budget 

>1 Under budget 


<0 Behind schedule 
=0 On schedule 
>0 Ahead of schedule 


A measure of schedule efficiency. 
Expressed as the ratio of EV to PV. 
<1 Behind schedule 

=1 On schedule 

>1 Ahead of schedule 


Three walls have been 

completed at a planned cost of 

$250/wall, therefore: 

EV = $750 

We have earned the value of 

$750 of work (i.e. three walls 

Painted), but this work has 

actually cost us $400. So, the 

project is: 

m ahead of schedule (three walls 
Painted instead of two), and 

m under budget (it cost us 
$400 instead of the $750 
expected). 


Four walls at $250/wall 


BAC = $1000 
Cv = $750 — $400 
CV = +$350 


That is, the work achieved cost 
$350 less than expected. 


CPI = $750 / $400 

CPI = 1.88 

We are spending at greater 
efficiency than expected. 


SV = $750 — $500 

SV = +$250 

We are $250 ahead in terms of 
what we planned to achieve. 


SPI = $750/ $500 

SPI = 1.5 

We are achieving 1.5 times the 
work we expected. 


ES = C + | (meaning the number of complete periods (C) plus an 


incomplete portion (I)) 


AT = actual time (the actual time duration from the project beginning 
to the time at which project status is assessed) 


Refer to the graph below for a visual explanation. 

m Earned schedule is at month 4 (April) 

@ Planned schedule at the reporting date is month 5 (May) 
Therefore, we can say that the project is 1 month behind schedule. 


Reporting date 


(today) 







Jan Feb March April 
Time 


Earned value 


Planned value 





Earned 
schedule (t) 


May June 


If the ES(t) line was at the reporting date line, then we would be 


on schedule. 
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SP(t) = ES / AT 


VAC = BAC — EAC 


How to interpret 





| Example 





ES = C + I (meaning the number of complete periods (C) plus an 


incomplete portion (I)) 


AT = actual time (the actual time duration from the project beginning 
to the time at which project status is assessed) 
le. Whatis the earned schedule efficiency? 


Cost variance at completion. VAC 
indicates expected actual over- or 
under-+un cost at completion. 
Positive (>0) Under planned cost 
=0 On planned cost 

Negative (<0) Over planned cost 


Refer later terms in this table for 
calculation, however it would be: 
VAC = $1000 — $532 

VAC = +$468 

The project will be under 
planned cost at completion. 





SPI(t) Schedule 
Performance Index 
(time) 

VAC Variance at 
completion 

EAC 


(Estimate at completion) 


ETC 
Estimate To Complete 


TCPI 
To Complete Performance Index 


TSPI 
To Complete Schedule Performance 
Index 


IEAC(t) 
Independent Estimate at Completion 
(time) 


EAC = BAC / CPI 


EAC = AC + New ETC 


EAC = AC + BAC — EV 


EAC = AC + (BAC — EV) / 
(CPI * SPI) 


ETC = EAC — AC 


ETC = Re-estimate 


TCPI = (BAC — EV) / 
(BAC — AC) 


TSPI(t) = (PD — ES) / 
(PD — AT) 

or 

TSPI(t) = (PD — ES) / 
(ED — AT) 


IEAC(t) = PD / SPi(t) 

or 

IEAC(t) = AT + (PD — ES) 
1 PF(t) 


EAC if CPI remains the same. 


EAC if original is flawed. 

New ETC = new estimate to 
complete, if the original estimate is 
based on wrong data/assumptions 
or circumstances have changed. 


EAC if BAC remains the same. 

EV = earned value, the variance is 
caused by a one- time event and is 
not likely to happen again. 


EAC if substandard performance 
continues. 

If both CPI and SPI are changing 
and influence the remaining work. 


Estimated cost to complete 
remaining work, assuming the 
work is proceeding to plan. 


Where a bottom-up re-estimate of 
the work is required. 


<1 Under budget 
=1 On budget 
>1 Over budge 


EAC = $1000/ 1.88 

EAC = $532 

As of now, how much we expect 
the total project to cost if the 
CPI remained the same till end 
of project (i.e. the original 
estimation is not accurate). 


NA in this project. 


NA in this project. 


NA in this project. 


ETC = $532 — $400 

ETC = $132 

We will have to spend an 
estimated additional $132 to 
complete the project and paint 
all four walls of the large meeting 
room. 


TCPI = ($1000 — $750)/ 
(1000 — 400) 

TCPI = 0.42 

TCPI indicates the project is 
running under budget at this 
time. 


Can the project be completed as planned? 


Can the project be completed as estimated? 
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Five careful steps can ensure that the cost/schedule system is integrated. These steps are 
outlined here. Steps 1, 2 and 3 are accomplished in the Planning stage. Steps 4 and 5 are sequentially 
accomplished during the Executing stage of the project. 

1. Define the work using a WBS. This step involves developing documents that include the following 

information (see Chapter 7): 

(a) scope 

(b) work packages 

(c) deliverables 

(d) organisational units 

(e) resources 


(f) budgets (for each work package). 


2. Develop work and resource schedule (see Chapter 9). 
(a) Schedule resources to activities. 


(b) Time-phase work packages into a network. 


3. Develop a time-phase budget using work packages (see Chapter 10). 


The cumulative values of these budgets will become the baseline and will be called the planned 
budgeted cost of the work scheduled (PV). The sum should equal the budgeted amounts for all the 
work packages in the WBS (cost accounts). 


4. At the work package level, collect the actual costs for the work performed. These costs will be 
called the actual cost of the work completed (AC). 


Collect per cent complete of each work package and multiply this by the original budget amount 
for the value of the work actually completed. These values will be called earned value (EV). 


Oo 


Calculate the schedule variance (SV = EV — PV) and cost variance (CV = EV — AC). 


Figure 11.3 presents a schematic overview of the integrated information system, which includes the 
techniques and systems presented in earlier chapters. Those who have tenaciously laboured through 
the early chapters can smile! Steps 1, 2 and 3 are already carefully developed. 

The major reasons for creating a baseline are to monitor and report progress and to estimate cash 
flow. Therefore, it is crucial to integrate the baseline with the performance measurement system. 
Costs are placed (time-phased) in the baseline exactly as managers expect them to be ‘earned’. This 
approach facilitates tracking costs to their point of origin. In practice, the integration is accomplished 
by using the same rules in assigning costs to the baseline as those used to measure progress using EV. 
You may find several rules in practice, but per cent complete is the workhorse most commonly used. 
Someone familiar with each task estimates what percentage of the task has been completed or how 
much of the task remains. 


11.5.1 Per cent complete rule 


Here, the question that is being asked is: What rule is being applied by the project manager to track 
the percentage complete of any task? This rule is the heart of any EV system. The best method for 
assigning costs to the baseline under this rule is to establish frequent checkpoints over the duration of 
the work package and assign completion percentages in dollar terms. For example, units completed 
could be used to assign baseline costs and later to measure progress. Units might be lines of code, 
hours, drawings completed, cubic yards of concrete in place, workdays, prototypes complete, 
and so on. This approach to per cent complete (% complete) adds objectivity to the subjective 
observation approaches often used. When measuring per cent complete in the monitoring stage of the 


Figure 1.3 P 
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ement information system ove: 





Scope 
deliverables 


WBS 


Work packages 


Time 
Resources 


OBS 


Labour 

Materials 
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Responsibilities 
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Control 


Time, cost, and 
specifications 
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deliverables 
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Plan, 
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project, it is common to limit the amount earned to 8@ or 9@ per cent until the work package is 10@ per 


cent complete. Other options discussed later in this chapter include: 


@ actual per cent complete (as discussed above) 
m 6/10@ per cent complete rule 

m interval per cent complete 

a 


50/50 rule. 


The project manager should agree and document how ‘% complete’ is to be determined, and 


document it in the Time Management Plan accordingly. 


11.5.2 What costs are included in baselines? 


The baseline planned value (PV) is the sum of the WBS work packages (cost accounts)—that is, it is 


the budget at completion (BAC) for the entire project. Three direct costs are typically included in 


baselines—labour, plant and equipment, and materials. The reason: these are direct costs the project 


manager can control. Overhead costs and profit are typically added later by accounting processes. 


Most work packages should be discrete, of short time span and have measurable outputs. If materials 


and/or equipment are a significant portion of the cost of work packages, they can be budgeted in 


separate work packages and cost accounts. Remember, the project BAC should include all incurred 


project costs. 


11.5.3 The basis of EVM 


Generally, the method for measuring accomplishments centres on two key calculations: 


1. Comparing EV with the expected schedule value. 


2. Comparing EV with the actual costs. 
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These comparisons can be made at the project level or down to the cost account level. Project 
status can be determined for the latest period, all periods to date and estimated to the end of the 
project. Assessing the current status of a project using EVM requires three data elements: 


@ planned cost of the work scheduled (PV). 
E budgeted cost of the work completed (EV). 


m actual cost of the work completed (AC). 


From these data items, the schedule variance (SV) and cost variance (CV) are calculated for 
each reporting period. A positive variance indicates a desirable condition, while a negative variance 
suggests problems or changes that have taken place. 


@ CV tells us if the work accomplished costs more or less than was planned at any point over 
the life of the project. If labour and materials have not been separated, CV should be reviewed 
carefully to isolate the cause to either labour or materials—or to both. 


m SV presents an overall assessment of all work packages in the project scheduled to date. It is important 
to note SV contains no critical path information. SV measures progress in dollars rather than time units. 
Therefore, it is unlikely that any translation of dollars to time will yield accurate information telling if 
any milestone or critical path is early, on time or late (even if the project occurs exactly as planned). 
The only accurate method jor determining the true time pregress of the project is to compare the 
project network schedule against the actual network schedule te measure if the project is on time. 


Figure 11.4 presents a sample cost/schedule graph with variances identified for a project at the 
current status report date. Note the graph also focuses on what remains to be accomplished and any 
favourable or unfavourable trends. The ‘today’ label marks the report date (time period 25) of where 
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Figure 11.5 Earned value review exer 
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the project has been and where it is going. Because our system is hierarchical, graphs of the same form 
can be developed for different levels of management. In Figure 11.4 the top line represents the actual 
costs (AC) incurred for the project work to date. The middle line is the baseline (PV) and ends at the 
scheduled project duration (45). The bottom line is the budgeted value of the work actually completed 
to date or the EV. The dotted line extending the actual costs from the report date to the new estimated 
completion date represents revised estimates of expected. actual costs; that is, additional information 
suggests the costs at completion of the project will differ from what was planned. Note that the project 
duration has been extended and the variance at completion (VAC) is negative (BAC — EAC). 

Another interpretation of the graph uses percentages. At the end of period 25, 75 per cent of the 
work was scheduled to be accomplished. At the end of period 25, the value of the work accomplished 
is 50 per cent. The actual cost of the work completed to date is $340, or 85 per cent of the total project 
budget. The graph suggests the project will have about an 18 per cent. cost overrun and be five 
time units late. The current status of the project shows the cost variance (CV) to be over budget by 
$140 (EV — AC = 200 — 340 = —140). The schedule variance (SV) is negative $100 (EV — PV = 200 
— 300 = —100), which suggests the project is behind schedule. Before moving to an example, consult 
Figure 11.5 to practise interpreting the outcomes of cost/schedule graphs. Remember, PV is your 
baseline and anchor point for the project. 


11.6 DEVELOPING A STATUS REPORT: 
A HYPOTHETICAL EXAMPLE 


Working through an example demonstrates how the baseline serves as the anchor from which the 
project can be monitored using EV techniques. 


11.6.1 Assumptions 


Because the process becomes geometrically complex with the addition of project detail, some 
simplifying assumptions are made in the example to more easily demonstrate the process: 


1. Assume each cost account has only one work package, and each cost account will be represented 
as an activity on the network. 


Nw 


The project network early start times will serve as the basis for assigning the baseline values. 


3. From the moment work on an activity task begins, some actual costs will be incurred each period 
until the activity is completed. 
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11.6.2 Baseline development 

Figure 11.6 depicts asimple WBS for a digital camera. There are six deliverables (Design Specifications, 
Shell and Power, Memory/Software, Zoom System, Assemble and Test) and five responsible 
departments (Design, Shell, Storage, Zoom and Assembly). The total for all the cost accounts (CA) 
is $320 000, which represents the total project cost. Figure 11.7, derived from the WBS, presents a 
planning Gantt chart for the digital camera project. The planned project duration is 11 time units. This 
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Figure 11.8 Digital Camera Prototype project baseline budget 
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project information is used to time-phase the project budget baseline. Figure 11.8 presents a worksheet 
with an early start baseline developed with costs assigned. They are assigned exactly as managers 
plan to monitor and measure schedule and cost performance. 


11.6.3 Development of the EVM status report 


A status report is analogous to a camera snapshot of a project at a specific point in time. The status 
report uses EV to measure schedule and cost performance. Measuring EV begins at the work package 
level. Work packages are in one of three conditions on a report date: 

1. Not yet started. 

2. Completed (finished). 


. Partially completed (in progress). 


EVs for the first two conditions present no difficulties. Work packages that are not yet started earn 
zero per cent of the PV (budget). Packages that are completed earn 100 per cent of their PV. Inprocess 
packages apply the per cent complete rule to the PV baseline to measure EV. In our camera example 
we will only use the per cent complete rule to measure progress. 

Table 11.3 presents the completed, separate status reports of the Digital Camera Prototype project 
for periods 1 through 7. Each period per cent complete and actual cost was gathered for each task 
from staff in the field. The schedule and cost variance are computed for each task and the project to 
date. For example, the status in period 1 shows only Task A (Design Specifications) is in process and 
itis 50 per cent complete and actual cost for the task is 10. 

The planned value at the end of period 1 for Task A is 10 (see Figure 11.8). The cost and SV are both 
zero, which indicates the project is on budget and schedule. By the end of period 3, Task A is finished. 
Task B (Shell and Power) is 33 per cent complete and AC is 10; Task C is 20 per cent complete and AC 
is 30; and D is 60 per cent complete and AC is 20. 

Again, from Figure 11.8 at the end of period 3, we can see that the PV for Task A is 20 (10 + 10 = 20), 
for Task Bis 5, for Task C is 20 and for Task Dis 15. At the end of period 3, it is becoming clear the actual 
cost (AC) is exceeding the value of the work completed (EV). The CV (see Table 11.3) for the project at 
the end of period 3 is negative 24. SV is positive 6, which suggests the project may be ahead of schedule. 

It is important to note that since EVs are calculated from costs (or sometimes labour hours or other 
metrics), the relationship of costs to time is not oneforone. For example, it is possible to have a negative 
SV variance when the project is actually ahead on the critical path. Therefore, it is important to remember, 
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Table 11.3 Digital Camera Prototype status reports: Periods 1-7 


Cost variance CV =EV — AC 
Schedule variance SV=EV—PV 
Status report: Ending period 1 


Task %complete EV cv SV 





A 50% 10 10 10 o [0] 
Cumulative totals 10 10 10 o o 
Status report: Ending period 2 

[ %complete 

A Finished 20 30 20 = 110) o 
Cumulative totals | | 20 | 30 | 20 | 210 | 

Status report: Ending period 3 

Task %complete w | ac in See ey 
A Finished 20 30 20 =10 | o 
B | 33% 5 10 5 =5) 

g 20% E Li Ln Ean o 
D | 60% 21 20 15 +1 +6 
Cumulative totals 66 90 60 — 24 +6 
Status report: Ending period 4 

Task | complete EV AC PV cU sv: 
A Finished 20 30 20 —10 [0] 
B Finished 15 20 15 25 ie} 
Cc | 50% 50 70 50 20) ie} 
D 80% RES | a +3 
Cumulative totals 113, 150 110 —37 +3 


Status report: Ending period 5 





A Finished 20 30 20 | —10 o 
B Finished 15 20 15 a5 [0] 
C | 60% 60 100 | 80 | —40 —20 
D 80% 28 50 35 -22 | =1/ 
Cumulative totals 123 200 | 150 =72/ | z2r 
Status report: Ending period 6 

%complete { 
A Finished 20 30 20 —10 | (0) 
B Finished 15 20 15 =5 | [0] 
C 80% 80 110 | 100 =30 | —20 
D Finished 35 60 35 -25 ie} 
Cumulative totals 150 220 170 —70 —20 
Status report: Ending period 7 
Task %complete EV AC PV cv sV 
A Finished 20 30 | 20 | —10 10) 
B “Finished 15 20 | 15 =>5 
© 90% 90 120 100 —30 —10 
D “Finished ss co a l sso! 
E (0% o| a a a | =o 
F 0% o o o o o 





Cumulative totals 160 230 200 —70 —40 
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SV is in dollars and is not an accurate measure of time; 
Figure 11.9 Digital Camera Prototype summary graph ($000) 





however, it is a fairly good indicator of the status of the 
whole project in terms of being ahead or behind schedule 
after the project is over 20 per cent complete. Only the 
project network, or tracking Gantt chart, and actual work 
completed can give an accurate assessment of schedule 











performance down to the work package level. 

By studying the separate status reports for periods 
5 through 7, you can see the project will be over budget 
and behind schedule. By period 7, Tasks A, B and D are 
finished, but all are over budget—negative 10, 5 and 
25. Task C (Memory/Software) is 90 per cent complete. 
Task E is late and hasn't started because Task C is not 








Dollars 








yet completed. The result is that, at the end of period 7, 
the Digital Camera project is over budget $70 000, with 
a schedule budget over $40 000. 

Figure 11.9 shows the graphed results of all the 
status reports through period 7. This graph represents 
the data from Table 11.3. The cumulative actual costs 
(AC) to date and the budgeted costs to date (EV) are 
plotted against the original project baseline (PV). The 
cumulative AC to date is $230; the cumulative EV to date is $160. Given these cumulative values, the cost 
variance (CV = EV — AC) is negative $70 (160 — 230 = —70). The schedule variance (SV = EV — PV) 
is negative $40 (160 — 200 = —40). Again, recall that only the project network or Tracking Gantt chart 
can give an accurate assessment of schedule performance down to the work package level. 

A Tracking Gantt bar chart for the Digital Camera Prototype is shown in Figure 11.10. From this 
figure you can see Task C (Memory/Software), which had an original duration of four time units, now 
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is expected to require six time units. This delay of two time units for Task C will also delay Tasks E 
and F two time units and result in the project being late two time periods. 

Figure 11.11 shows an oversimplified project roll-up at the end of period 7. The roll-up is by 
deliverables and organisational units. For example, the Memory/Software deliverable has an SV of 
$ —10 and a CV of —30. The responsible ‘Storage’ department should have an explanation for these 
variances. Similarly, the Assembly department, which is responsible for the Assemble and Test 
deliverables, has an SV of $ —30 due to the delay of Task C (see Figure 11.10). Most deliverables look 
unfavourable on schedule and cost variance. 

In more complex projects, the crosstabs of cost accounts by deliverables and organisational units 
can be very revealing and more profound. This example contains the basics for developing a status 
report, baseline development and measuring schedule and cost variance. In our example, performance 
analysis had only one level above the cost account level. Because all data is derived from the detailed 
database, it is relatively easy to determine progress status at all levels of the work and organisation 
breakdown structures. Fortunately, this same current database can provide additional views of the 
current status of the project and forecast costs at the completion of the project. Approaches for 
deriving additional information from the database are presented next. 

To the uninitiated, a caveat is in order. In practice, budgets may not be expressed in total dollars 
for an activity. Frequently, budgets are time-phased for materials and labour separately for more 
effective control over costs. Another common approach used in practice is to use labour hours in 
place of dollars in the EV system. Later, labour hours are converted to dollars. The use of labour 
hours in the EV system is the modus operandi for most construction work. Labour hours are easy 
to understand and are often the way many time and cost estimates are developed. Most EV software 
easily accommodates the use of labour hours for development of cost estimates. 
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11.7 EARNED VALUE MANAGEMENT (EVM) INDEXES 
TO MONITOR PROGRESS 


Practitioners sometimes prefer to use schedule and cost indexes over the absolute values of SV and 
CV because indexes can be considered efficiency ratios. Graphed indexes over the project life cycle 
can be very illuminating and useful. The trends are easily identified for deliverables and the whole 
project. 

Indexes are typically used at the cost account level and 
above. In practice, the database is also used to develop Table 11.4 Interpretation of indexes 
indexes that allow the project manager and customer 

5 A A s Index Cost (CPI) Schedule (SPI) 

to view progress from several angles. An index of 1.00 
>1.00 Under cost Ahead of schedule 
=1.00 On cost On schedule 


(100 per cent) indicates progress is as planned. An index 
greater than 1.00 shows progress is better than expected. 
An index less than 1.00 suggests progress is poorer than <1.00 Over cost Behind schedule 
planned and deserves attention. Table 11.4 presents the 

interpretation of the indexes. 


11.7.1 Performance indexes 


There are two indexes of performance efficiency. The first index measures cost efficiency of the work 
accomplished to date (data from Table 11.3): 


Cost Performance Index (CPI) = EV/AC = 160/230 = 0.696 or 0.70 


The CPI of 0.696 shows that $0.70 worth of work planned to date has been completed for each $1.00 
actually spent—an unfavourable situation indeed. The CPI is the most accepted and used index. It has 
been tested over time and found to be the most accurate, reliable and 
stable. 






































The second index is a measure of scheduling efficiency to date: Figure 1112 Indexes periods 1-7 
Schedule Performance Index (SPI) = EV /PV = 160/200 = 0.80 120 
1.10 Az 
The schedule index indicates $0.80 worth of work has been ool —— Cie alee eae | 
accomplished for each $1.00 worth of scheduled work to date. i Å + 
Figure 11.12 shows the indexes plotted for our example project 90 \ Y A 
through period 7. This figure is another example of graphs used in 80 r SY SPI =.80 
ractice. 
P .70 VA A F=] CPI=.70 
x 
3 60 | 
11.7.2 Project per cent complete indexes 50 L> PCIB = 50 
Two project per cent complete indexes are used, depending a 
on your judgement of which one is most representative of your 
project. The first index assumes the original budget of work 
complete is the most reliable information to measure project 
per cent complete. The second index assumes the actual costs 
to date and expected cost at completion are the most reliable for 


























measuring project per cent complete. These indexes compare 
the to-date progress to the end of the project. The implications Time periods 
underlying use of these indexes are that conditions will not 
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change, no improvement or action will be taken, and the information in the database is accurate. 
The first index looks at per cent complete in terms of budget amounts: 


Per cent Complete Index (budget costs) (PCIB) = EV/BAC = 160/230 = 0.50 (50%) 


This PCIB indicates the work accomplished represents 50 per cent of the total project budget (BAC) 
dollars to date. Observe that this calculation does not include actual costs incurred. Because actual 
dollars spent do not guarantee project progress, this index is favoured by many project managers 
when there is a high level of confidence in the original budget estimates. 

The second index views per cent complete in terms of actual dollars spent to accomplish the work to 
date and the actual expected dollars for the completed project (EAC). For example, at the end of period 
7 the staff reestimates that the EAC will be 575 instead of 320. The application of this view is written as: 


Per cent Complete Index (actual costs ) (PCIC) = AC/EAC = 230/575 = 0.40 (40%) 


Some managers favour this index because it contains actual and revised estimates that. include 
newer, more complete information. 

These two views of the per cent completed present alternative views of the ‘real’ percentages 
completed. These percentages may be quite different, as shown above. 

Note: The PCIC was not plotted in Figure 11.12. The new figures for EAC would be derived each 
period by estimators in the field. 


11.7.3 Technical performance measurement 


Measuring technical performance is as important as measuring schedule and cost performance. 
Although technical performance is often assumed, the opposite can be true. The ramifications of 
poor technical performance frequently are more profound—something works or it doesn’t if technical 
specifications are not adhered to. 

Assessing technical performance of asystem, facility or product is often accomplished by examining 
the documents found in the scope statement and/or work package documentation. These documents 
should specify criteria and tolerance limits against which performance can be measured. For example, 
the technical performance of a software project suffered because the feature of ‘drag and drop’ was 
deleted in the final product. Conversely, the prototype of an experimental car exceeded the kilometres 
per litre technical specification and, thus, its technical performance. Frequently tests are conducted on 
different performance dimensions. These tests become an integral part of the project schedule. 

It is very difficult to specify how to measure technical performance because it depends on the 
nature of the project. Suffice it to say, measuring technical performance must be done. Technical 
performance is frequently where quality control processes are needed and used. Project managers 
must be creative in finding ways to control this very important. area. 


11.7.4 Software for project cost/schedule systems 


Software developers have created sophisticated schedule/cost systems for projects that track and 
report budget, actual, earned, committed and index values. These values can be labour hours, materials 
and/or dollars. This information supports cost and schedule progress, performance measurements 
and cash flow management. Remember that budget, actual and committed dollars usually run in 
different timeframes. A typical modern project management software package would have the ability 
to produce the following project information: 

@ schedule variance (EV — PV) by cost account and WBS and OBS 

m cost variance (EV — AC) by cost account and WBS and OBS 

m indexes, Cost Performance Index (CPI) and Schedule Performance Index (SPI) 
E 


cumulative actual total cost to date (AC) 
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@ expected costs at completion (EAC) 


@ paid and unpaid commitments. 


Software developers and vendors have done a superb job of providing software to meet the 
information needs of most project managers. Differences among software in the last decade have 
centred on improving userfriendliness and output that is clear and easy to understand. Anyone who 
understands the concepts and tools presented in this text should have little trouble understanding the 
output of any of the popular project management software packages. 


11.7.5 Additional earned value (EV) rules 


Although the per cent complete rule is the mostused method of assigning budgets to baselines and 
for cost control, there are additional rules that are very useful for reducing the overhead costs of 
collecting detailed data on per cent complete of individual work packages (an additional advantage 
of these rules, of course, is that they remove the often subjective judgements of the contractors or 
estimators as to how much work has actually been completed). The first two rules are typically used 
for short-duration activities and/or small-cost activities. The third rule uses gates before the total 
budgeted value of an activity can be claimed. 


=m 0/100 rule: This rule assumes credit is earned for having performed the work once it is 
completed. Hence, 100 per cent of the budget is earned when the work package is completed. 
This rule is used for work packages having very short durations. 


m 50/50 rule: This approach allows 50 per cent of the value of the work package budget to be 
earned when it is started and 50 per cent to be earned when the package is completed. This rule 
is popular for work packages of short duration and small total costs. 


@ Interval rule: Some organisations use a fixed interval per cent complete rule, rounding down to 
25 per cent, 50 per cent or 75 per cent intervals. However, the intervals can take on any set of 
interval values as defined by the organisation. Nete: Intervals of ‘thirds’ are also popular. 


@ Per cent complete with weighted monitoring gates: This more recent rule uses subjective 
estimated per cent complete in combination with hard, tangible monitoring points. This method 
works well on long-duration activities that can be broken into short, discrete work packages of 
no more than one or two report periods. These discrete packages limit the subjective estimated 
values. For example, assume a long-duration activity with a total budget of $500. The activity is 
cut into three sequentially discrete packages with monitoring gates representing 30, 50 and 100 
per cent of the total budget. The earned amount at each monitoring gate cannot exceed $150, 
$250 and $500. These hard monitoring points serve as a check on overly optimistic estimates. 


Notice the only information needed for the first two rules is that the work package has started and 
the package has been completed. Appendix 11.1 (online) applies the first two rules along with the per 
cent complete rule. The third rule is frequently used to authorise progress payments to contractors. This 
rule supports careful tracking and control of payments; it discourages payment to contractors for work 
not yet completed. See Fleming & Koppelman (2006) for an excellent discussion of applying EV rules. 


11.8 FORECASTING FINAL PROJECT COST 


There are basically two methods used to revise estimates of future project costs. In many cases, both 
methods are used on specific segments of the project. The result is confusion of terms in texts, in software 
and among practitioners in the field. We have chosen to note the differences between the methods. 

The first method allows experts in the field to change original baseline durations and costs because 
new information tells them the original estimates are not accurate. We have used estimated cost at 
completion—revised estimates (EAC,,) to represent revisions made by experts and practitioners 
associated with the project. The revisions from project experts are almost always used on smaller projects. 
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The equation for calculating revised estimates (EAC,,) is as follows: 
EAC „e = AC + ETC. 
where: 
EAC,, = revised estimated cost at completion 


AC = cumulative actual cost of work completed to date 


ETC,, = revised estimated cost to complete remaining work. 


Asecond method is used in large projects where the original budget is less reliable. This method 
uses the actual costs to date plus an efficiency index (CPI = EV / AC) applied to the remaining project 
work. When the estimate for completion uses the CPI as the basis for forecasting cost at completion, 
we use the acronym EAC ;. 

The equation for this forecasting model (EAC,) is as follows: 


EAC, = ETC + AC 


Work remaining BAC — EV 
CPI EV/AC 





ETC = 





where: 


EAC; = estimated total cost at completion—forecasted 
ETC = estimated cost to complete remaining work 

AC = cumulative actual cost of work completed to date 
CPI = cumulative cost index to date 

BAC = total budget of the baseline 

EV = cumulative budgeted cost of work completed to date. 


The following information is available from our earlier example; the forecast estimated cost at 
completion (EAC;) is computed as follows: 


Total baseline budget (BAC) for the project $320 
Cumulative earned value (EV) to date $160 
Cumulative actual cost (AC) to date $230 
Work remainin: BAC — EV 
ETC eis 








CPI © EV/AC 
EAC, = 459 


The final project projected cost forecast is $459 000, versus $320 000 originally planned. 

Another popular index is the To Complete Performance Index (TCPD), which is useful as a 
supplement to the estimate at complete (EAC;) computation. This ratio measures the amount of value 
each remaining dollar in the budget must earn to stay within the budget. The index is computed for 
the Digital Camera Prototype project at the end of period 7. 


BAC—EV _ 320—160 _ 160 
BAC — AC 320 — 230 90 


TCPI = = 178 





The index of 1.78 indicates that each remaining dollar in the budget must earn $1.78 in value. There 
is more work to be done than there is budget left. Clearly, it would be tough to increase productivity 
that much to make budget. The work to be done will have to be reduced or you will have to accept 
running over budget. If the TCPI is less than 1.00, you should be able to complete the project without 
using all of the remaining budget. A ratio of less than 1.00 opens the possibility of other opportunities 
such as improving quality, increasing profit or expanding scope. 
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Research data indicates that on large projects that are more than 15 per cent complete, the model 
performs well with an error of less than 10 per cent. This model can also be used for WBS and OBS cost 
accounts that have been used to forecast remaining and total costs. It is important to note that this 
model assumes conditions will not change, the cost database is reliable, EV and AC are cumulative and 
past project progress is representative of future progress. This objective forecast represents a good 
starting point or benchmark that management can use to compare other forecasts that include other 
conditions and subjective judgements. 

Table 11.5 presents an abridged monthly status report similar to one used by a project organisation. 
The form is used for all projects in the organisation’s project portfolio. (Note that the SV of —$22 176 
does not translate directly to days. The 25 days were derived from the network schedule.) 


Table 11.5 Monthly status report 2010 


Project number: 163 Project manager: Connor Gage 
Project priority now: 4 
Status as of: 1 April 2017 


Earned value figures: 


PV EV AC sv cv BAC 
588 240 566 064 596 800 =22 176 =30 736 1051 200 
EAC VAC EAC, CPI PCIB Pcic 
1 090 640 —39 440 1 107 469 -95 538 547 


Project description: A computer-controlled conveyor belt that will move and position items on the belt with accuracy 
of less than one millimetre. 


Status summary: The project is approximately 25 days behind schedule. The project has a CV of ($30 736). 


Explanations: The SV has moved from non-critical activities to those on the critical path. Integration first stage, 
scheduled to start 26/3, is now expected to start 19/4, which means it is approximately 25 days behind schedule. 
This delay is traced to the loss of the second design team which made it impossible to start utilities documentation on 
27/2 as planned. This loss illustrates the effect of losing valuable resources on the project. The CV to date is largely 
due to a design change that cost $21 000. 


Major changes since last report: The major change was loss of one design team to the project. 


Total cost of approved design changes: $21 000. Most of this amount is attributed to the improved design of the 
serial I/O drivers. 


Projected cost at completion: EAC; is estimated to be $1 107 469. This represents an overrun of $56 269, given a 
CPI of .95. The CPI of .95 causes the forecast to be greater than the VAC -$39 440. 


Risk watch: Nothing suggests the risk level of any segments has changed. 


Another summary report is shown in the Snapshot from Practice: Trojan decommissioning project. 
Compare the differences in format. 


SNAPSHOT FROM PRACTICE Trojan decommissioning project 





Portland General Electric Company was charged with 
decommissioning the Trojan Nuclear Plant. This is a 
long and complex project extending over two decades. 
The first segment of the project of moving the used 
reactors to a storage location is complete and was 
awarded the Project of the Year in 2000 by the Project 
Management Institute (PMI). Note that the Nuclear 
Regulatory Commission certified the Trojan Nuclear Plant 
as radiologically decommissioned in 2005. Structural 
demolition of remaining generating plant structures 
was completed in 2008. The remainder of the project— 
decontamination of the remaining structures and waste— 
is ongoing. 


Table 11.6 shows the projects EV status report 
through December 2000. This report measures schedule 
and cost performance for monitoring the project. The 
report also serves as a basis for funding. 

The SPI (0.94) suggests the project schedule is falling 
behind. Resolving issues witha major vendor and solutions 
for technical problems should solve these delay problems. 
The CPI (1.14) for the project is positive. Some of this good 
cost performance is attributed to partnering and incentive 
arrangements with vendors and labour unions. 


Source: Interview with Michael B. Lackey, general manager, Trejan, Portlanel 
General Electric, September 2001. 


Table 11.6 Cost/oudget performance 


Cost/Budget Perfor! | Decommissioning Cumulative Costs Nominal Year Dollars 


Portland General Electric Co.- | Report Run: 23-Jan-01 8:13 A.M. Report Number: DECTO05 
Trojan Nuclear Plant 





Year-to-Date YTD 
Variance 
EV-AC 

Description [Ev AC PV Ev AC 

ISFSI 193014 182 573 162579 3 655 677 3586 411 3263.995 322 416 3655677 1.10 0.98 
RVAIR o ie} o ie} (0) 399 (399) ie} 0.00 0.00 
Equip removal—AB/FB 79 083 79 649 73 899 497 197 504 975 308 461 196 514 497 197 1.64 1.02 
Equip removal—other ie} io} ie} io} (36 822) 519 (37 341) io} 0.00 0.00 
Embed piping—AB/FB 3884 ie} 2118 532 275 540 232 515235 24 997 532 275 1.05; 1.01 
Embed piping—other o ie} 3 439 175 401 210 875 79235 131 640 175401 2.66 1.20 
Surface decon—AB/FB 29935 23 274 21456 1 266 685 12930315 1 ASM 121 603 1 266 665 1.10 1.02 
Surface decon—other 2875 2 11 005 308 085 199 853 251 265 (51 412) 308 085 0.80 0.65 
Surface decon—containment 680 502 435 657 474 427 5271 889 4 950 528 4 823 338 127 190 5 271 889 1.03 0.94 
Radwaste disposal 884 873 453 032 (28 675) 10680 118 8276616 10807916 (2531300) 10880118 0.77 0.77 
Final survey 58 238 57 985 27 091 780 990 780 990 700 942 80 048 780 990 Tail 1.00 
Non-radiological areas 92 837 91 956 58 538 2471 281 2 376 123 834 643 1541 480 2 471 281 2.85 0.96 
Staffing 714806 714509 468 858 9 947 775 9947 775 8 241 383 1706 392 9 947 775 Ta 1.00 
ISFSI—Longterm ops 85026 85028 TNS 2 004 398 2 004 398 337 206 1667 192 2 004 398 5.94 1.00 
Labour loadings 258 289 258 289 240 229 3216 194 3216 194 2 755604 460 590 3216 194 taz 1.00 
Material loadings 17910 17910 (95 128) 211 454 211 454 136973 74481 211454 1.54 1.00 
Corporate governance 153689 228 499 228521 1814 523 1814 523 1814520 3 1814523 1.00 1.00 
Undistributable costs 431 840 401 720 242 724 5541679 5575 879 4 007 732 1 567 947 5541679 1.39 1.01 
Total decommissioning 3688481 3008081 1905084 48375399 45453119 40051079 5402040 48 375399 143 0.94 


Total (less ISFSI and RVAIR) 3 493467 2845508 1743485 44719720 41886710 36 788680 5080024 44719720 1.14 0.94 
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11.9 OTHER CONTROL ISSUES 
11.9.1 Scope creep 


As introduced in Chapter 7, large changes in scope are easily identified. It is the ‘minor refinements’ 
that. eventually build to be major scope changes that can cause problems. These small refinements 
represent scope creep. For example, the customer of a software developer requested small changes 
in the development of a custom accounting software package. After several minor refinements, it 
became apparent the changes represented a significant enlargement of the original project scope. The 
result. was an unhappy customer and a development firm that lost money and reputation. 

Although scope changes are usually viewed negatively, there are situations when scope changes 
result in positive rewards. Scope changes can represent significant opportunities. In product 
development environments, adding a small feature to a product can result in a huge competitive 
advantage. A small change in the production process may get the product to market one month early 
or reduce product cost. 

Scope creep is common early in projects—especially in new-product development projects. 
Customer requirements for additional features, new technology and poor design assumptions all 
manifest pressures for scope changes. Frequently, these changes are small and go unnoticed until 
time delays or cost overruns are observed. Scope creep affects the organisation, project team and 
project suppliers. Scope changes alter the organisation's cash flow requirements in the form of fewer 
or additional resources, which may also affect other projects. Frequent changes eventually wear 
down team motivation and cohesiveness. Clear team goals are altered, become less focused and 
cease being the focal point for team action. Starting over again is annoying and demoralising to the 
project team because it disrupts project rhythm and lowers productivity. Project suppliers resent 
frequent changes because they represent higher costs and have the same effect on their team as on 
the project team. 

The key to managing scope creep is change management. One project manager of an architectural 
firm related that scope creep was the biggest risk his firm faced in projects. The best defence against 
scope creep is a well-defined scope statement. Poor scope statements are one of the major causes of 
scope creep. 

A second defence against scope creep is stating what the project is not, which can avoid 
misinterpretations later (refer back to Chapter 7 and the authors’ top 20 items to be included in the 
scope document). First, the original scope baseline must be well defined and agreed upon with the 
project customer. Before the project begins, it is imperative that clear procedures be in place for 
authorising and documenting scope changes by the customer or project team. If a scope change 
is necessary, the impact on the baseline should be clearly documented—for example, cost, time, 
dependencies, specifications, responsibilities and so on. Finally, the scope change must be quickly 
added to the original baseline to reflect the change in budget and schedule; these changes and their 
impacts need to be communicated to all project stakeholders. 


11.9.2 Baseline changes 


Changes during the life cycle of projects are inevitable and will occur. Some changes can be beneficial 
to project outcomes; changes having a negative impact are the ones we wish to avoid. Careful project 
definition can minimise the need for changes. The price for poor project definition can be changes 
that result in cost overruns, late schedules, low morale and loss of control. Change comes from 
external sources or from within. Externally, for example, the customer may request changes that 
were not included in the original scope statement and that will require significant. changes to the 
project and thus to the baseline. Or the government may introduce requirements that were not a part 
of the original plan and that require a revision of the project scope. Internally, stakeholders may 
identify unforeseen problems or improvements that change the scope of the project. In rare cases, 
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scope changes can come from several sources. For example, 
the Denver International Airport automatic baggage handling 
system was an afterthought supported by several project 
stakeholders that included the Denver city government, 
consultants and at least one airline customer. The additional 
US$2 billion in costs were staggering, and the airport opening 
was delayed 16 months. If this automatic baggage scope 
change had been in the original plan, costs would have been 
only a fraction of the overrun costs and delays would have 
been reduced significantly. Any changes in scope or the 
baseline should be recorded by the change management 
system that was established by the project during the 
Initiating stage in the scope management plan. 

Generally, project managers monitor scope changes very 
carefully. They should allow scope changes only if it is clear 
that the project will fail without the change, the project will 
be improved significantly with the change, or the customer 
wants it and will pay for it. This statement is an exaggeration, 
but it sets the tone for approaching baseline changes. The 
effect of the change on the scope and baseline should be 
accepted and signed off by the project customer. Figure 11.13 


depicts the cost impact of a scope change on the baseline at a point in time—‘today’. Line A represents 


a scope change that results in an increase in cost. Line B represents a scope change that decreases 


cost. Quickly recording scope changes to the baseline keeps the computed EVs valid. Failure to do so 


results in misleading cost and schedule 


variances. 


Care should be taken not to use baseline changes to disguise poor performance on past or current 


work. A common signal of this type of baseline change is a constantly revised baseline that seems 


SNAPSHOT FROM PRACTICE A pseudo-EV per cent complete approach 





A consultant for the US Forest Service suggested the 
use of EV to monitor the 50-plus timber sale projects 
taking place concurrently in the district. As projects were 
completed, new ones were started. EV was tried for 
approximately nine months. After the nine-month trial, the 
process was to be reviewed by a task force. The task force 
concluded the EV system provided good information for 
monitoring and forecasting project progress; however, the 
costs and problems of collecting timely per cent complete 
data were unacceptable because there were no funds 
available to collect such data. 

The level of detail dilemma was discussed, but 
no suggestions satisfied the problem. The discussion 
recognised that too little data fails to offer good control, 
while excessive reporting requires paperwork and people, 
which are costly. The task force concluded progress and 
performance could be measured using a pseudo-version 
of per cent complete while not giving up much accuracy 


for the total project. This modified approach to per cent 
complete required that very large work packages (about 
3-5% of all work packages in a project) be divided 
into smaller work packages for closer control and 
identification of problems sooner. It was decided work 
packages of about a week's duration would be ideal. 
The pseudoversion required only a telephone call and 
‘yes/no’ answers to one of the following questions to 
assign per cent complete: 


Has work on the work package started? No = 0% 
Working on the package? Yes = 50% 
Is the work package completed? Yes = 100% 


Data for the pseudo-EV per cent complete system 
was collected for all 50-plus projects by an intern 
working fewer than eight hours each week. 
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to match results. Practitioners call this a ‘rubber baseline’ because it stretches to match results. Most 
changes will not result in serious scope changes and should be absorbed as positive or negative 
variances. Retroactive changes for work already accomplished should not be allowed. Transfer of 
money among cost accounts should not be allowed after the work is complete. Unforeseen changes 
can be handled through the contingency reserve. The project manager typically makes this decision. 
In some large projects, a partnering ‘change review team’, made up of members of the project and 
customer teams, makes all decisions on project changes. 


11.9.3 The costs and problems of data acquisition 


Data acquisition is time consuming and costly. Snapshot from Practice: A pseudo-EV per cent complete 
approach captures some of the frequent issues surrounding resistance to data collection of per cent 
complete for EV systems. Similar pseudoper cent complete systems have been used by others. Such 
pseudoper cent. complete approaches appear to work well in multiproject environments that include 
several small and mediumsized projects. Assuming a one-week reporting period, care needs to be 
taken to develop work packages with a duration of about one week so problems are identified quickly. 
For large projects, there is no substitute for using a per cent complete system that depends on data 
collected through observation at clearly defined monitoring points. 

In some cases, data exists but is not sent to the stakeholders who need information relating to 
project progress. Clearly, if the information does not reach the right people in a timely manner, you 
can expect serious problems. Your communication plan developed in the projectplanning stage can 
greatly mitigate this problem by mapping out the flow of information and keeping stakeholders 
informed on all aspects of project progress and issues—refer to Chapter 16. 


11.10 FURTHER PROJECT PERFORMANCE 
CONSIDERATIONS 


E Referring back to the triple constraints, one of the primary factors a project manager needs to 
be evercognisant of is quality. Maintaining quality in a project is key to being able to deliver 
the project’s outcomes and outputs required by the customer (whether internal or external to the 
organisation). Reviewing the ‘quality’ performance aspects of the project is important to ensuring 
the project deliverables are in accordance with the specified quality tolerance criteria. Making 
sure projects achieve their quality outcomes is the focus of Chapter 12. 


E In Australia, safety is often a critical component of project performance. Without. specifying, 
monitoring and achieving safety performance criteria, other activities in the project might not 
even be able to take place. Monitoring and reporting on safety performance criteria can form 
an important aspect of a project, particularly across building, construction, mining and utility 
infrastructure projects. There are many industry-accepted safety performance criteria and some 
commonly encountered performance measures include the following: 


— Lagging performance indicators: 
m lost time injury frequency rate (LTIFR) 
m lost time injury incidence rate (LTIIR) 
m medically treated injury frequency rate (MTIFR) 
E average time lost rate (ATLR) 
— Leading performance indicators: 
E average compliance of internal workplace health and safety (WHS) verification audits 


m WHS training delivery. 
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The Workplace Health and Safety Department of an organisation within which a project is to take 
place will often mandate a set of safety performance metrics, and policy and procedures. Some useful 
sources of workplace health and safety information include: 


— https//www:safeworkaustralia.gov.au 
— AS/NZS 4801:2001 Occupational Health and Safety Management Systems 
— www.ohsbok.org.au 


— ISO 45001, the recently published (2018) global standard on occupational health and safety. 


A project manager charged with ensuring all project safety concerns are addressed should be 
certain to involve relevant subject matter experts at an early stage since, as with quality, all aspects of 
implementing safety measures will undoubtedly add additional activities to the project and therefore 
costs and time; however, safety should never be compromised at the expense of other project criteria. 


E Environmental performance reporting can be as important as safety, as the financial costs of 
environmental incidents, including plant, animal and human, can be exorbitant. An example of 
this is the 2010 BP Deepwater Horizon oil platform disaster—aside from the unfortunate initial 
loss of life, the subsequent cleanup operations cost BP US$38 billion, and the costs are still rising. 
Adverse environmental impacts can take the form of: 


— pollution incidents, including run-off, tailings and chemical spills 


— damage to environmentally sensitive land areas, including damage to flora, fauna and wildlife by 
chemical or mechanical means 


— cultural heritage impacts, including the encroachment and destruction into traditional and histori- 
cal Aboriginal land. 


Defining and ensuring relevant environmental performance criteria are adhered to, and reported 
on, is another aspect of project performance that a project manager must consider in some 
projects. One of the most common standards against which environmental performance is 
managed in an organisation (or within a project that ‘takes on’ environmental aspects) is the 
standard AS/NZS ISO 14001:2004 Environmental Management Systems. 


E The human dimensions of project performance can also forma critical aspect to report on. For 
example, in a large software development project, a ‘key enabler’ to the delivery of the project on 
cost, on schedule and to quality are the people engaged in developing the software code. Without 
tightly written and agreed performance agreements (discussed in Chapter 14), the monitoring of 
individuals and reporting on their performance could, if left unchecked, put the project at risk. 
Monitoring the performance of the human elements of a project is often more challenging than 
other more tangible performance aspects of project performance management. Reporting on 
human performance can be achieved using various measures. In the example above, the lines 
of code produced (to coding standards) could be selected as the chosen method by which to 
measure human performance for coding outcomes. 


The best information system does not result in good control. Control requires the project manager to use good-quality, 
reliable and accurate information to steer the project through rough waters. Control and Gantt charts are useful tools 
for monitoring time performance. The cost/schedule system allows the manager to have a positive influence on cost 
and schedule in a timely manner. The ability to influence cost decreases with time; therefore, timely reports identifying 
adverse cost trends can greatly assist the project manager in getting back on budget and schedule. The integrated 
cost/schedule model provides the project manager and other stakeholders with a snapshot of the current and future 
status of the project. The benefits of the cost/schedule model are as follows: 
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Measures accomplishments against plan and deliverables. 

Provides a method for tracking directly to a problem work package and organisational unit responsible. 
Alerts all stakeholders to early identification of problems, and allows for quick, proactive corrective action. 
Improves communication because all stakeholders are using the same database. 


oP wpe 


Keeps customers informed of progress, and encourages customer confidence that the money spent is resulting in the 
expected progress. 
6. Provides for accountability over individual portions of the overall budget for each organisational unit. 


With your information system in place, you need to use your communication plan to keep stakeholders informed so 
timely decisions can be made to ensure the project is managed effectively. 


Review the following three short video clips on EVM: 


Part 1 https://www.youtube.com/watch?v=UggTFk2EiUg 
Part2 https://www.youtube.com/watch?v=jJi 1FxC2e64 
Part3 https://www.youtube.com/watch?v=-MJEYc48C js 


https://infostore.saiglobal.com/en-gb/Standards/AS-4817-2006-R20 16--318360/ 

www.earnedschedule.com 
www.earnedschedule.com/Docs/Earned%20Schedule%20-%20New%20analysis%200f%20schedule%20in%20EVM.pdf 
https://www.apm.org.uk/media/1233/earned-schedule.pdf 

https://www.iso.org/news/ref227 1.html?utm_medium=email&utm_campaign=ISO%20Newsletter%20March%20 


201 8&utm_content=ISO%20Newsletter%20March%20201 8+CID_bd4f44f96ea22c82e84f57af1293a478&utm_ 
source=Email%20marketing%20software&utm_term=overview%200f%20the%20standard 


https://www.iso.org/standard/63787.html 
https://www.iso.org/iso-45001-occupational-health-and-safety.html 
https://www.iso.org/standard/3 1807.html 


budget at completion (BAC) estimated cost at completion— planned value (PV) 

control chart revised estimates (EAC e) quality 

Cost Performance exception reporting Schedule Performance Index (SPI) 
Index (CPI) full reporting schedule variance (SV) 

cost variance (CV) milestones scope creep 

earned schedule (ES) Per cent Complete Index—actual To Complete Performance Index 

earned value (EV) costs (PCIC) (TCPI) 

estimated cost at completion— Per cent Complete Index—budget tracking Gantt chart 
forecasted (EAC ,) costs (PCIB) variance at completion (VAC) 


Review questions 


How does a tracking Gantt chart help communicate project progress? 

How does EVM provide a clearer picture of project schedule and cost status, over a simple plan versus actual system? 
SV is in dollars and does not directly represent time. Why is it still useful? 

How would a project manager use the CPI? 

What are the differences between BAC and EAC? 


Why is itimportant for project managers to resist changes to the project baseline? Under what conditions would a 
project manager make changes to a project baseline? 


Pawn a 


7. Besides a cost and schedule performance, what other aspects of project performance may have to be reported on 
and why? 


8. What type of reports could the project manager be asked to prepare throughout the life cycle of a project? 
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4. In month 9, the following project information is available: actual cost is $2000, EV is $2100 and planned cost is $2400. 
Compute the SV and CV for the project. 

2. On day 51, a project has an EV of $600, an actual cost of $650 and a planned cost of $560. Compute the SV, CV and 
CPI for the project. What is your assessment of the project on day 51? 

3. Given the project network and baseline information below, complete the form to develop a status report for the project 
at the end of period 4 and the end of period 8. From the data you have collected and computed for periods 4 and 8, 
what information are you prepared to tell the customer about the status of the project at the end of period 8? 
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Project baseline (PV) 
(in $) 
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Period PV total 500 















































Cumulative PV total 3700} 





End of period 4 
Task Actual % complete 





A Finished =s 300 400 == == 
B 50% = 1000 800 == == 
Ẹ 33% == 500 600 = = 
D 0% == o == me =e 
E 0% 


Cumulative totals 
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End of period 8 





Task | Actual % complete EV AC | PV cv SV 
A Finished == 300 400 == == 
B Finished —— 2200 2400 = —— 
[o Finished —— 1500 1500 —— —— 
D 25% —— 300 [0] —— —— 
E 33% — 300 —— —— —— 
B 0% — [0] —— —— —— 


Cumulative totals —— 





4. Given the following project network, baseline and status information, develop status reports for periods 2, 4, 6 and 8 
and complete the performance indexes table. Calculate the EAC ¿andthe VAC, Based on your data, what is your 
assessment of the current status of the project? At completion? 

















































































































LEGEND 
TEA ES | ID | EF 
2 | 2 
SL SL 
6 | 4 |10 
2 EBS |S LS our] LF 
1 1 
S D J10 10| F |12 
5 5 |5 |10 10] 2 |12 
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Budget 

ID | ($000) 
1 2 3 4 5 6 Fi 8 9 10 11 12 

A 40 10 | 10 | 10 | 10 
B 32 8 4 8 4 8 
le 48 2S || Ws RE it. 
D 18 6 | 2 | 2 | 2 | 6 
E 28 8 | 8 | HP? | | 
E 40 | | | | 20 | 20 
Total 206 18 | 14 | 18 | 14 | 20 | 26 | 22 | 26 | 2 | 6 20 | 20 
Cumulative 18 | 32 | 50 | 64 | 84 | 110] 132] 158 | 160 | 166 | 186 | 206 
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Status report: Ending period 2 ($000) 

e mee eV Tw ee | 
A 75% —— 25 — — —— 
B 50% _ == 12 = = == 
Cumulative totals = — 37 —— pam 5R 
Status report: Ending period 4 ($000) 

cv | sv 
A 100% —— 35 — —— —— 
B 100% = 24 — —— —— 
Cumulative totals —— —— 59 —— —— —— 


Status report: Ending period 6 ($000) k| 








LCa ea 
A 100% —— 35 =s = 
B 100% | — 24 =a == == 
ic 75% = 24 == = | == 
D 0% = Oo —— — = 
E 50% —— 10 —— = a= 
Cumulative totals = — 93 —— == a 





Status report: Ending period 8 


[000) 
== 35 =S ES = 


A 100% 

B 100% == 24 =a uae a= 
E 100% =] 32 == = == 
D 33% == 20 == == == 
E 100% =a ero r= =m m 
Cumulative totals = =5 93 =m S pm 


Performance Indexes summary 


Frertormanceindexes summary O 
C a E a a 
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4 = 
6 — 
8 = 
EAC, = VAC, = 


























































































































5. Given the following project network, baseline and status information, develop status reports for periods 1—4 and 
complete the project summary graph (or a similar one). Report the final SV, CV, CPI and PCIB. Based on your data, what 
is your assessment of the current status of the project? At completion? 

OF Ae 2/4/4 

1 ||| 1 1 1 
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QO) 2) 3 304/450 45 Se. 6 

[0] 0 p 0 0 m 0 Oo 

Oo) 3 | 3 3: 2h 1.45 Sth E.: 

LEGEND 
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Schedule information Baseline puagetineeds 


















































($000) 
ae DUR ES LF SL Ka Ls, ee : 
1 2 Oo 3 4 12 4/8 
2 3 Oo 3 [0] 15 5 
3 2 [0] Fi Oo 8 4|4 
4 2 2 5 1 6 3 
5 2 3 5 Oo 10 6/4 
6 3 2 5 ie} 9 33 
7 1 5 6 ie} 5 5 
Total PV by period |11 |19|11|12|7 |5 
Cumulative PV by period |11 |30 |41 |53 | 60 |65 

















Status report: Ending period 1 ($000) 


| % complete 





Cumulative totals = 7 —— = 

Task | % complete EV AC PV cv sv 
1 Finished == 13 == == == 
2 80% —— 14 == ees, ES 
3 75% == 8 —— — — 
Cumulative totals — 35 == == = 


Status report: Ending period 3 | ($000) 
Task % complete EV AC PV | cv 
1 





Finished 12 13 = =s 2s 
2 80% —— 15. —— == =s, 
3 Finished —— 10 —— — — 
4 50% —— 4 —— coe =n 
5 0% —— [0] —— == =S 
6 33.3% —— 4 —— — Am 
Cumulative totals 
Status report: Ending period 4 ($000) 
Task | % complete EV AC PV | cv sv 
1 Finished 12 13 —— — eS 
2 Finished 15 18 —— == aa 
3 Finished —— 10 —— =A == 
4 Finished = 8 —— — = 
5 30% —— 3 —— = es 
6 66.7% =] 8 = = 
7 0% —— [0] —— — So 


Cumulative totals 
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Summary graph 
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6. The following labour hours data have been collected for a nanotechnology project for periods 1 through 6. Compute 
the SV, CV, SPI and CPI for each period. Plot the EV and the AC on the summary graph provided (or a similar one). Plot 





























































































































the SPI, CPI and PCIB on the index graph provided (or a similar one). What is your assessment of the project at the end 
of period 6? 
2 5 
— | 
2 4 
1 3 7 
2 6 2 
Legend 
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Schedule information 


Baseline budget needs—labour hours (00) 








LF Time period 
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Total PV by period 





Cumulative PV by period 






































Status report: Ending period 1 
Task % complete 


1 50% 
Cumulative totals 


Status report: Ending period 2 


Ev 


1 Finished 
Cumulative totals — 1500 2000 — — 


Status report: Ending period 3 


frase [compete SST rv | vc dT wT 
1 
2 
Bi 
4 


Finished 2000 1500 2000 == == 
0% — o = == == 


Cumulative totals —— 2200 == EFS = 
Status report: Ending period 4 


1 Finished = 2000 1500 2000 

2 50% == 1000 == == == 
3 30% = 800 == = == 
4 40% == 1500 == == == 


Cumulative totals 


4800 


Continued 
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Labour hours 


Continued 


Status report: Ending period 5 


a E A C C E 


Finished 
2 Finished 
3 50% 
4 60% 
5 25% 
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Status report: Ending period 6 
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7. The following data has been collected for a British health care IT project for two-week reporting periods 2—12. 
Compute the SV, CV, SPI and CPI for each period. Plot the EV and the AC on the summary graph provided. Plot the SPI, 
CPI and PCIB on the index graph provided. (You may use your own graphs.) What is your assessment of the project at 
the end of period 12? 


































































































4] 2]12 14] 7 [18 
2 c e ok 
f x 
6 |8 |14 / 14/4 [ra] y 
4 % 
LA x 
’ x 
/ `N 
1 3 |10 10] 5 1a MEE 8 |22 
===310 0 b===5-| 0 E ° f o o 
4 6 |10 10| 4 |14 18| 4 |22 
Legend 
4[4]38 3]6|16 ESHDA LER 
2 2 S| 2 il 2 SL we 
6 | 4/10 10| 8 [18 LS [DUR] LF 












































Baseline (PV; 
{$00) 








PV 


($00) 0 8 10 12 14 16 18 20 22 





8 





40 





30 





20 





40 








60 





20 





B/P]o;AR| aA] Ol ola 


ie} 30 




















Period PV total 








Cumulative PV total 
































PART 3 DEFINING AND MANAGING PROJECTS 


Status report: ET period 2 Maai 
BERL ¢ |% kaaa CE 


Cumulative totals —— 4 —— — ed 


Status report: Ending period 4 o0 
co ca 


Finished 
Cumulative totals — 10 —— — S 


Status report: Ending period 6 ($00) 
aee kerete E A 





Finished — == 
2 25% —_— 15 — pea =e 
3 33% = 12 = == =a 
4 0% —— o —— == EE 
Cumulative totals = 37 — as =s 





fl Finished —— 10 =e ER mea 
2 30% = 20 as == == 
3 60% = 25 Ss = el 
4 0% = o = =z Ta 
Cumulative totals = 55 —— == == 





% complete 
1 Finished -- 10 = pean = 
2 60% —— 30 == 2= ates 
3 Finished —— 40 — a == 
4 50% = 20 —— == 5 
5 0% = [0] — = =A 
6 30% == 24 eS EE = 
Cumulative totals = 124 == — = 


Status report: Ending period 12 





% complete 


1 Finished —— 10 = == = 
2 Finished —— 50 — == ae 
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6 50% 40 — = == 
Cumulative totals = 210 = — == 
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Summary graph 
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Additional exercises, solutions to selected exercises and appendices are available online. 
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PROJECT QUALITY MANAGEMENT 





Learning elements 


Establish what ‘quality’ means in the project environment. 


Be able to establish a culture and process around continuous improvement in the 
project environment. 


Plan the quality assurance (QA) and quality control (QC) requirements of the 
project. 


Understand the different tools and techniques used to control and monitor quality. 


Be able to investigate defects by applying root-cause analysis techniques. 


In this chapter 


12.1 Introduction 

12.2 Quality and project management 

12.3 Cost of quality (CoQ) and cost of poor quality (CoPQ) 
12.4 Continuous improvement 

12.5 Planning for quality assurance and quality control 
12.6 Carrying out quality control 

12.7 Root-cause analysis 

12.8 Scrum (Agile) considerations 


Summary 
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12.1 INTRODUCTION 


Quality is a critical aspect of project management. Its definition not only forms the basis of articulating 
the required level of quality, it is also a critical element in the management of the triple constraints. 
The triple constraints were previously introduced in Chapter 7 (Figure 7.5) and as noted, ‘quality’ 
sits at the centre of the triangle. The project manager essentially manages the aspects of scope, time 
and cost while trying to protect (or not impede) the quality criteria of the project. As indicated in 
Chapter 7, there may be a point where quality has to be sacrificed (by agreement) in order to complete 
the project on time and on cost. 

Many aspects of quality are woven through the project life cycle. Discussions around quality 
should start from the outset of a project; within the Initiating stage of the project life cycle. 

The two key aspects of quality that must be considered are: 


1. Project quality management: The focus here is on setting the project management quality 
expectations, deciding how these will be measured and how improvements will be made during 
the life cycle of the project—for example, specifying how and when project ‘health checks’ will 
take place to ensure conformance to project governance criteria. 


2. Product/service (or result) quality management: Here, the focus is on the product and/or service 
being produced from the project, for the enduser or customer of the project. For example, a 
touch screen display forming part of an aircraft cockpit console would require identifying the 
required specifications; defining the tolerances for these specifications; and defining how quality 
will be checked, at what point in the proceedings, and by whom. 


12.2 QUALITY AND PROJECT MANAGEMENT 


Before delving further into a discussion of quality and project management, it’s important to first 
clarify understanding of some of the common terminology that will be used in this section. 

When scoping a project, discussions must move from talking about requirements for quality at a 
high, overarching level and move towards a tight definition of the criteria of quality. Perceptions of what 
will actually constitute quality will have been discussed with the customer and will have been translated 
into ‘broad brush’ quality requirements during the Initiating stage of the project (discussed in Chapter 
7) or in fact, even before project development within the Business Case (discussed in Chapter 4). The 
customer's quality requirements are often referred to as the voice of the customer (VoC). The VoC 
is critical—after all, if the project does not understand what the customer wants and how success is 
measured, how can accurate requirements be defined for what needs to be delivered from the project? 
It is therefore the project manager’s responsibility to ensure that the customer’s perceptions and their 
requirements are researched, clarified, documented and agreed upon. This forms part of the project 
scoping activities at the Initiating stage of the project, and then is further detailed in the Planning stage 
of the project, in development of the Quality Management Plan and other associated artefacts. 


12.3 COST OF QUALITY (COQ) AND THE COST 
OF POOR QUALITY (COPQ) 


During discussions about quality, the project manager is likely to be asked what the cost of quality 
(CoQ) is for the product/service being designed. CoQ includes both: (1) the cost of preventing a defect 
or rework (i.e. the costs incurred as a resulting of achieving quality), and (2) the cost of poor quality 
(CoPQ)—costs generated when poor quality occurs (e.g. recalls, reputation). 

For example, if Samsung had invested more into the prevention side of quality (CoQ), by ensuring 
the Galaxy Note 7 batteries manufactured by one of their own subsidiaries fitted the Note 7 case, it 
would have reduced or probably not had to count the cost of poor quality (i.e. the US$5 billion costs of 
recalls, replacements and reputation damage). 
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When the CoQ is incorporated into the design of the final project and resulting product or service, 
it could have many implications, including: 


a Estimation of the project costs: Higher quality usually means higher costs, whether in the 
components purchased, or in the use of higherquality service providers. 


E The need to consider the impact on the time taken to complete activities: This may now take 
longer and require additional steps, for example, to carry out additional quality control activities 
within work packages. 

@ The design of comprehensive quality control processes and general continuous improvement 
activities: To ensure that quality is being applied and improved throughout the life of the project 
(i.e. we are improving our own project management processes). 


If insufficient attention is paid to quality in general, many potential costs to the project can arise 
when deliverables are handed over (or post-project). These can include, for example, not achieving 
the required balance of product/service project quality, product/service defects, unnecessary rework, 
nonconformance and dissatisfied customers (see Table 12.1). 

In most situations, the project manager will work with the customer to define and negotiate 
acceptable levels of quality that meet both the customer's expectations (perceptions) and the project 
manager's ability to deliver these within agreed budget and time and scope parameters. 

The project manager could already be aware of the CoPQ such as those shown in Table 12.1. This is 
because documents such as the Business Case or the project Charter may have already outlined them. 
For example, the Charter’s problem statement might include aspects of poor quality. See Snapshot 
from Practice: Simple paving quandary for an example of lessons in project quality. This snapshot 
shows the effect of the CoPQ in the project management processes, in not identifying the relevant. 
quality criteria, resulting in a cost to the project and probably the customer (after all, someone has to 
pay for the rectification of the poor quality). 


Table 121 The costs of quality 


Cost of quality (CoQ) 
Cost of achieving good quality Cost arising from poor quality (CoPQ) 


Prevention costs (i.e. the cost of building quality into 
the process) 


Additional processes are developed and compliance to 
these processes are ensured, in order to achieve the 
quality outcomes. 


Training costs associated with training project staff 
and contractors to ensure quality requirements are 
understood and met. 


Increase in the cost of components to ensure these are at 
the required level of quality. 


Costs associated with purchasing the correct tools and 
equipment. 

Appraisal costs (i.e. the costs associated with checking 
for quality) 


Costs associated with the time and resources expended 
in conducting audits and project health checks. 


Checking the quality of products and services produced 
by the project. These additional checks to ensure the 
process is producing outputs correctly are costs that 
should be identified in the project. 

Testing components individually and further testing the 
integrated set of components as a system in the final 
product/service. If the product is destroyed during testing, 
this is referred to as ‘destructive testing’ (and has a greater 
cost, which is the cost of destroying the part being tested). 


Internal failure costs (i.e. the costs associated with 
reworking the defective product (or service) before it 
reaches the customer) 


Failing to ‘do it right the first time’ (DIRFT) necessitates 
additional time and cost to complete. 


The costs of reworking defective parts or service 
elements (e.g. a service desk ticket that is not resolved 
correctly and has to be re-opened and reworked by the 
service desk agents). 


A process fails to deliver the required outputs and 
has to be shut down until the root causes have been 
identified and corrected—before the process can be 
re-started. 


External failure costs (i.e. the costs associated with a 
defective product (or service) reaching the customer) 


Customer dissatisfaction and longerterm reputational 
damage (loss of future business). 


Increased risk of legal action being taken against the 
project and/or the organisation. 


Excessive warranty/defect claims, resulting in a cost to 
the project and/or organisation, in terms of rectification 
during and/or post-pro ject. 
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SNAPSHOT FROM PRACTICE Simple paving quandary 





A local council in Queensland established a project for a 
major mall redevelopment. The redevelopment required 
a substantial amount of external paving to be re-laid. 
In designing the project, the designers and engineers 
omitted to factor in the Australian Standards for quality 
specifications for pavers. The design utilised a natural 
paving material where the tolerances of the paver 
used were not consistent across its surface. When the 
client was involved in the sign-off of a deliverable for a 
section of the laid pavers, the surface was measured to 
ensure that a +/— 2 mm variance across the surface of 
the paver had been adhered to. As the pavers were a 
natural material, they did not meet these requirements 
and quality came into question. It was apparent that the 
client, project manager and designer did not have a clear 
understanding of the quality requirements of the pavers, 
even though in this case there were well-documented 
Australian Standards available for reference and inclusion 








Glow Images 


Units, Pavers, Flags and Segmental Retaining Wall Units). 
The standards had not been identified by any party in 
the project: not by the designer, the paving company 


as the quality criteria (e.g. AS/NZS 4455.2:2010 Masonry representative, or the project manager. 


12.4 CONTINUOUS IMPROVEMENT 


Before proceeding into the project management aspects of quality assurance and quality control, 
let's first delve into some of the background behind the process of continuous improvement and how 
this impacts the management of quality in a project environment. 


Continuous improvement is an ongoing effort to improve products, services or processes. 
These ef forts can seek ‘incremental’ improvement over time or ‘breakthrough’ improvement all 
at once (ASQ 2018a). 


There are a number of commonly applied approaches to continuous improvement, including the ‘Plan, 
Do, Check, Act’ cycle, Lean Six Sigma and, to a lesser extent today, total quality management (TQM). 


12.4.1 Plan, Do, Check, Act (PDCA) 


Many ISO 9001-accredited organisations follow the PDCA approach towards continuous improvement 
(ISO 9001 promotes PDCA as the preferred continuous improvement approach). PDCA (see Figure 12.2) 
is credited to Joseph Juran but. was later popularised by W. Edwards Deming. Deming (later) changed 
the word ‘Check’ to ‘Study’, arguing that we don't just check to see if something 
worked, or did not work—but rather we study this with interest, to understand 
more deeply what exactly happened. Refer to Table 12.2 for a definition 
and application of how the PDCA cycle might form the basis of continuous 
improvement in a project environment. 


Figure 12.2 The ‘Plan, Do, 
Check, Aci cle 


12.4.2 Lean Six Sigma 


Lean Six Sigma was introduced in Chapter 2. Six Sigma is a metric, a 
methodology and a management system. As a methodology it focuses on 
understanding customer requirements, alignment of key business processes, 
basing control on data, and embedding sustainable outcomes in the business. 
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Table 12.2 PDCA defined and applied 


z PDCA defined 


Define the problem to be addressed, 
collect relevant data and analyse this 


PDCA ISO 9001* de 





n PDCA example 
(applied to the management of a project) 


Establish the objectives ofthe system An issue has been identified with the change request 
and its processes, and the resources process. 


recommendations to improve the 
process in the next PDCA cycle. 


& data to ascertain the problem's root needed to deliver results in accordance Approvals for change requests have to wait until 
@ cause. Decide upon a measurementto with customers’ requirements and the the weekly meeting of the Change Management 
baseline the process and understand organisation's policies, and identify and Board (CMB). This is delaying project progress and 
what it is currently delivering. address risks and opportunities. frustrating the client. 
Develop and implement a solution; Implement what was planned. The project manager asked the project coordinator 
typically a ‘to-be’ process with to look into the situation. The project coordinator 
associated documents and system provided the following recommendations: 
RES m Revise the change request process. 
fe) m Devolve accountability for approval of the change 
a request to the project manager for changes <$3000 
in value and/or less than 0.5-day schedule slippage. 
m CBM to meet twice weekly for 30 minutes. 
These changes are subsequently implemented in the 
project environment. 
Confirm the results of ‘before’ Monitor and (where applicable) measure Check that change requests are being attended to in 
% (baseline) and ‘after’ (implemented processes and the resulting products a more timely manner and client satisfaction with the 
@ solution) data. Did we achieve what and services against policies, objectives, process. 
O we expected? requirements and planned activities, and 
report the results. 
Embed the change, inform others Take actions to improve performance, Further improve the change request process by 
F about process changes, and make as necessary. introducing an automated workflow of change 


requests to improve audittracking and integration 
with the PMIS. 


Source: ISO 9001 Quality Management Systems — Requirements, Sth edn., 2015, International Standares Organisation 


As a management system, the focus is on ensuring strategic alignment, using high-performing teams 
to attack specific continuous improvement projects to ensure results are sustained in the business. Six 
Sigma’s continuous improvement approach involves applying the Define, Measure, Analyse, Improve 
and Control (DMAIC) process (as introduced in Chapter 2). The core principle of Lean is to create 
customer value while minimising waste. This means creating increased value for customers, with 
fewer resources. The focus is on the key processes for increasing customer value; the goal being to 
provide defined customer value via a series of streamlined processes that do not produce waste. 

Lean Six Sigma brings both approaches together, but drives the process of improvement through 
the DMAIC process, rather than through the ISO-preferred approach of PDCA. Table 12.3 provides an 
example of the same change request issued through the DMAIC process. 


12.4.3 Total quality management (TQM) 


Total quality management (TQM) focuses on achieving 100 per cent customer satisfaction and zero 
defects, in business processes and quality supply chains. The main principles of TQM include prevention, 
zero defects, getting things ‘right’ the first time, ‘quality involves everyone’, continuous improvement 
and employee involvement. TQM is arguably rapidly falling out of use in favour of Lean Six Sigma. 


12.4.4 The Quality Management Plan 


Whichever overarching quality approach is taken, the importance (froma project management perspective) 
lies in leveraging continuous improvement to assist in the delivery of the project and the production of the 
resulting products and services. The overall objective is to define and manage quality because, as illustrated 
in Figure 12.3, the cost to rectify poor quality logarithmically increases across the life cycle of the project. 
When poor quality is passed into ‘business as usual’, the cost to rectify problems increases significantly. If 
poor quality reaches the customer, the cost is even greater as the company brand and reputation are often 
affected. A case in point is the Samsung Galaxy Note 7 mobile phone and its ‘exploding’ batteries—this 
defect issue is reported to have cost Samsung in excess of US$5 billion (Swider 2017). 


PART 3 DEFINING AND MANAGING PROJECTS 


Table 12.3 DMAIC continuous improvement example 


E DMAIC defined DMAIC example (applied to management of a project) 


Define 


Measure 


Analyse 


Improve 


Control 


Define and understand 
the problem being 
investigated in this 
cycle of continuous 
improvement. 


Understand the ‘as-is’ 
process, measure and 
establish a baseline 

from which to improve. 


Analyse the data and 
process in order to 
understand the root 
causes to the problem. 


Make suggestions for 
improving the root 
causes, and seek 
approval for the best 
solution(s) to implement 
in the business. 


Hand over the solution 
to the business—in this 
case project. 


Source: ® 2018 Dr Neil Pearson 


Figure 12.3 Cost to rectify quality defects across 


and beyond the project life cycle 





Cost to rectify defects 





An issue has been identified with the change request process. 


Problem statement: Approvals for change requests have to wait until the weekly meeting of the CMB. This is 
delaying project progress (by an average of three days per change request) and frustrating the client (lowering 
the project's customer engagement survey score by two points). 


Goal statement: Ensure minor change requests are attended to immediately (within one working day) and improve 
the customer engagement survey by 1.5 points, within two weeks of making improvements to the process. 

The customer was interviewed to find out what was critical to them—the cycle time of the process was 
confirmed as their key critical to quality (CTQ) measure. 

The project manager asked the project coordinator to look into the situation. The project coordinator mapped 
the current ‘as-is’ process as a Swimlane diagram and measured: 


— the average cycle time (minutes) to complete a change request 
— the average delay time (minutes) introduced by waiting for the CMB. 


The as-is process was baselined. 


The project coordinator analysed the ‘as-is’ process for value, waste and flow (these are key lean techniques) 
and also took a further exploratory data analysis of the work in progress change requests and cycle time of 
the process. 

From the value and flow analysis, it was observed there was a lot of waste in waiting at the CMB. They also 
detected some defects in change requests they were being sent back to the customer as all the information 
on the change had not been captured. 

These two root causes: 1. Delays waiting for the CMB, and 2. incorrect information provided by customer were 
taken forward to the Improve stage of DMAIC. 


In relation to: 


1. Delays waiting for the CMB, the recommendation was to (a) revise the change request process and devolve 
accountability for approval of the change request to the project manager for changes <$3000 in value and/ 
or less than 0.5-day schedule slippage (b) change the frequency and duration of the CBM to a twice weekly 
meeting of 30 minutes. 

2. Incorrect information provided by customer, the change request was made into an online form, with 
Mandatory fields complete with explanation of how to complete the form. 


These changes are subsequently approved by the sponsor and implemented in the project environment. 


A measure was taken against the measure defined in the ‘measure’ stage of DMAIC to see the positive effect 
the improvements had made on the change request process: 


— the average cycle time (minutes) to complete a change request 
— the average delay time (minutes) introduced by waiting for the CMB 
— customer engagement survey. 


The change request process was communicated to the customer and all project staff. The process was then measured 
ona weekly basis to ensure the improvements were being adhered to and the change was being sustained. 
Additionally, a suggestion was made to further improve the change request process by introducing an 
automated workflow of change requests to improve audit-tracking and integration with the PMIS. 


The Quality Management Plan is a product of the Planning 
stage of the project life cycle and forms one of the subsidiary 
plans to the Project Management Plan. From a quality 
perspective it sets out: 


E The desired approach te project quality. This includes 
an overarching statement that guides the project team in 
relation to quality. An example of this statement might be: 






‘Quality is the responsibility of everyone in the project 
team. At every opportunity, the project team is encouraged 
to seek opportunities to continually improve the internal 
process and systems related to the management of the 


Business as 


project. The project team must apply the change request. 
process of the project to those aspects of quality assurance 





Source: © 2018 Dr, Neil Pearson 


Time and quality control that affect the quality of the end 


product and/or service being delivered to the customer.’ 
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E The approach to continuous improvement: This explains whether a PDCA or DMAIC process 
will underpin the activities that all the project team may be involved in, in relation to either 1. 
Improving the processes around the project management of the project and/or 2. Improving the 
product/service (or result) produced by the project. 

E The roles and responsibilities of project team members and others involved in quality assurance 
and quality control: For example, stating who will be responsible in the project team for signing 
off the test certificates for all electrical installations of air-conditioning units to be installed in a 
newly constructed high rise of 402 apartments. 


E The quality criteria grid (refer Table 12.4) outlines highlevel quality requirements. This provides 
an ideal way to brainstorm and capture the standards, policies, technical specifications and 
legislation that have to be adhered to by the project; and the control mechanisms to be put in 
place to monitor quality of these when produced in the project. 

The assumptions and constraints related to planning and controlling quality in the project. 

Risk: This involves assessing activities for potential quality risks, by carrying out a risk 
assessment and updating the project's Risk Register, as appropriate. 

E Quantification and articulation of knock-on effects to the cost and time requirements of the 
project, arising from undertaking planned quality assurance and quality control activities. For 
example, if a stringent approach to quality is to be taken in the building of a hightech component 
of a satellite, what are the additional costs and schedule implications to doing this—what is the 
CoQ for including these extra activities? 

Links to other project documents that contain a detailed breakdown of each item (e.g. standard, 
specification, requirement, legislation) as captured in the quality criteria grid, from both a quality 
assurance (what) and quality control (hew) perspective. This may generate numerous additional 
quality assurance and quality control documents for certain components of the project (down to 
a work package level). 


Source: @ 2018 Dr Neil Pearson 





With reference to the last point: It is noteworthy that this could be achieved by generating a simple 
(yet extensive) table of detailed quality planning requirements. This would usually be undertaken 
during the Planning stage of the project, resulting in detailed documentation of the quality criteria 
and setting out how each of these quality criteria will be controlled in the project. An example of such 
a breakdown is included as Table 12.4. These additional Quality Plans at a more detailed level would 
supplement the project’s Quality Management Plan. On a large project there could potentially be many 
of these plans for the different aspects of the project. 


Table 12.4 Detailed mapping of quality assurance criteria and quality control mechanisms 


Source or standard | Quality criteria Category Acceptable tolerance | Occurrence | Control approach | Responsibility 


Project management PMO, project Project Business Case Monthly Review at project Project manager. 
office (PMO), governance, governance remains viable. steering committee Quorum of steering 
project governance Business Case meeting. committees 
requirements and review. members to confirm 
framework. acceptance. 
Product Enclosure meets Electrical 100% of sample Random Correct installation of Site manager. 
specification sheet the product selected meeting enclosure and earth 

for new low energy/ specifications, design installation connection according 

low-heat light electrical contacts drawings, with no to design drawings and 


enclosure. earthed to housing. earthing issues. specifications. 
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In summary, the Quality Management Plan assists in: 


m Removing discrepancies between the perceptions and perspectives of the sponsor, the customer and 
the project, by articulating and agreeing the key quality assurance requirements of the project and 
how the quality control aspects are planned to take place during the Executing stage of the project. 

Em Ensuring appropriate measures and control mechanisms (processes and checks) are put in place 
for each criteria prior to project execution. 


= Documenting and agreeing on the approach to continuous improvement in the project 
environment (PDCA or DMAIC). 


@ Clarifying the key project processes, roles and responsibilities in relation to quality. 


Decisions made in the early planning of quality can have long lasting effects on the deliverables of 
the project. Figure 12.3 amply illustrates this. 

Snapshot from Practice: VET Quality Framework describes a situation where a project manager 
begins to identify the quality assurance and quality control aspects required of an organisation when 
registering to become a registered training organisation (RTO), in Australia. 


SNAPSHOT FROM PRACTICE VET Quality Framework 





A non-accredited training organisation has recently made 
the strategic decision to become a registered training 
organisation (RTO). in order to do so, the organisation 
must comply with the guidelines of the Australian Skills 
Quality Authority (ASQA). A project was established by the 
director of the organisation and the project is currently in 
the Planning stage. The project manager has started to 
review the quality aspects of the project, to prepare for 
developing the project’s Quality Management Plan, and in 
doing so has located the following information: 


m The VET Quality Framework is aimed at achieving greater 
national consistency in the way providers are registered 
and monitored and in how standards in the vocational 
education and training (VET) sector are enforced. 





m The VET Quality Framework comprises: 
1, the standards for National VET Regulator (NVR) RTOs 
2. the ‘fit and proper person’ requirements 
3. the ‘financial viability risk assessment’ requirements 
4. the ‘data provision requirements’ and the Australian 
Qualifications Framework. 


Due to the nature of the registration process, RTOs have 
to adopt these standards (quality assurance criteria) and 
further develop quality control processes for the RTO as a 





part of the project. The project manager documents these 
requirements in the project's Quality Management Plan. 

Further to this, the project manager has been in contact 
with stakeholders in their stakeholder network from other 
RTOs, and has been given ideas about two key processes 
for the control of quality in the RTO, which they consider the 
project must produce. The project manager documents 
these in the Quality Management Plan and adds two 
additional work packages to the project's WBS. The work 
packages are titled: ‘Development of the course student 
feedback sheet and continuous improvement process’ 
and ‘Development of the facilitator course feedback sheet 
and continuous improvement process’. 

The project manager now tasks a business analyst 
(BA) to review the VET Quality Framework guidelines and 
take on the further development of the project's Quality 
Management Plan. The BA is asked to bring any further 
work packages resulting from the review to the attention 
of the project manager as these will subsequently need 
to be included in the project’s WBS, project budget and 
other project documents. 


Source: VET information sourced from Australian Skills Quality Authority 
(ASQA) n.d., ‘VET Quality Framework’, ASGA, https://www.asqa.gov.au/about/ 
australias-vetsector/vet-qualityframework, accessed February 2018, 


12.4.5 Processes: helpful techniques 


The world of quality brings together a number of process modelling techniques, whether these process 
are related to the: 


E project management-related processes such as the change request process introduced in Chapter 7, or 


@ deliverables of the project, for example, a customer engagement process for the introduction of a 
new Customer Relationship Management (CRM) system. 
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One of the more popular techniques for mapping out a process involves developing a ‘SIPOC’. The 
SIPOC is a relatively simple tool that is used to map out a process at. a high level—we could use this 
technique during the scoping of the project, for example. Figure 12.4 illustrates a partial SIPOC, with 
a simple example of introducing a new CRM system (it focuses the project manager on the underlying 
business process; the CRM system is just the enabler to the process). Understanding the scope of the 
process is important. as it will influence the scope of the project. 

The way to construct the SIPOC is indicated in the (SIPOC) table headings. Additionally, ‘M1’, 
‘M2’ etc. indicate where the process is to be measured (these could be turned into operational level 
agreements with/between internal departments or even service level agreements with/between 
external parties). These measures could even be the ‘quality criteria’ used to measure the success of 
the project later on, from either an internal or an external perspective. 

Beyond the SIPOC (taking the understanding of the process to the next level of detail) are the 
process models themselves. Here, the project manager could use a variety of process modelling 
techniques, with the most simple being a flowchart. In practice, the most commonly used modelling 
technique however is a process Swimlane diagram. When developing a SIPOC, start with the process 
(1), define the outputs (2) and map to which customer (8) these are delivered to. Then come back 
and detail the inputs (4) and who supplies (5) these inputs. Finally, add a key to the table as shown in 
Figure 12.4. Don't just number the tiles—add an object (square) with the number inside it. 


Input/s Process Output/s Customer 


Supplier 


Fifth, list who supplies 
each of the inputs 


Fourth, list the inputs 
to the process step. 


First, list the major 
process steps. 


Second, list the outputs 
(incl. outcomes) from 
the step. 


Third, list which 
outputs eceived 
by which customers 





Customer Customer 1. Customer profile Customer profile Business 
information established development 
department 
Business Detail of business 2. Allocate business Updated customer Business 
development development development profile development 
department manager manager manager 
Customer Discussion 3. Capture initial Updated customer Business 
customer contact profile development 
M2 department 
pete: 


Count of new customers 
logged per month 


Count of new customers 


not contacted with 10 
business days 


Source: © 2018 Dr Neil Pearsen 
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Processes and flowcharts are instrumental in being 
Figure 12.5 Simple flowchart able to achieve quality in a repeatable, measurable way. 


Invoke 


emergency 
plan 


Source: © 2018 Dr Neil Pearson 





Processes and flowcharts map out the activities to be 
completed for a particular activity. In mapping out the 
activities, existing or new measures can be overlaid onto 
the process. When a process or flowchart of activities 
can be measured, then the quality of that process can 
be measured and therefore subsequently monitored and 
controlled. A simple flowchart (with measures shown) is 
illustrated in Figure 12.5. 

In Figure 12.5, four measures take place: Mi—the 
number and time of calls going into the system; M2—the 
number and time of calls/requests that are not emergency- 
related; M3—the number and times of calls/requests 
post-emergency response; and M4—the number and time 
of non-emergency calls, post-diagnosis and treatment. 
From this simple flowchart, it would be possible (for 
example) to calculate the time taken for a request at M1 
to be triaged and responded to as an emergency (M4). 
This information could then be tracked ona control chart 
for analysis as part of a project deploying an emergency 
response service desk. Refer to Snapshot from Practice: 
Service desk project, measuring the process, for an 
example of the importance of process measurement. 

Another popular approach to capturing processes is 
to use a Swimlane diagram. Two industry best-practice 
approaches to capturing processes in the Swimlane 
format include: business process model and notation 
(BPMN™) and unified modelling language (UML*) 
activity diagrams (UML will be left. for the reader to 
explore in other texts). 

In BPMN, actors (a role, or department/group, or IT system) are represented as swimlanes 
combined with a special set of notation (symbols) and a set of business rules, which ensures all 
elements of a process are fully captured. In a project environment this has the benefit of: 


™ capturing the project management processes, to achieve quality in the management of the project 
™ capturing the processes related to the deliverables of the project, so the end product/service, once 


handed over to the business/customer, has repeatable processes to support ongoing operations 
(in BaU). 


For a detailed resource on BPMN refer to the Object Management Group's website at www.omg. 
org/spec/BPMN/2.0/ and for an accessible snapshot to the BPMN notation refer www.bpml.de/images/ 
BPMN2_0_Poster_EN.pdf. 

Note: An example of a project change request process using the BPMN notation was introduced 
in Chapter 7 (in Figure 7.18). These BPMNstyle Swimlane diagrams are fast becoming the de facto 
standard in businesses to capture organisational processes. The project manager will frequently find 
that they are either modifying (improving) existing Swimlane diagrams as a part of the project's 
deliverables, or designing new processes (in the Swimlane format) to be handed over to the business 
at the end of the project. 

Opportunities for continuous improvement can come from both formal project quality control 
mechanisms and from informal channels (such as suggestion boxes or innovation registers). Together, 
they can create a learning project environment where ideas for continuous improvement are captured, 
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SNAPSHOT FROM PRACTICE Service desk project, measuring the process 





A large software company had initiated a project to establish 
a 24/7, multilingual, internal IT service desk. The project had 
multiple streams of work running concurrently, including 
streams to develop the telephony infrastructure, survey and 
agree on languages, decide on the best business locations 
to geographically locate the three service centres, and a 
stream to define the staffing requirements and develop all 
the internal service processes. 

The project manager was actively involved in the 
design of the ‘staffing requirements and development of 
all the internal service processes’ stream, and negotiating 
the service desk measures about what the ‘quality 
of service’ would look like when implemented in the 
business. 

Based on ITIL (IT Infrastructure Library) best practice, 
the service desk processes were developed. However, 
discussions continued on how process quality was to be 
measured. Ultimately the process measures would form 
part of the service desk agents’ performance agreements 
when handed over to the business at the end of the project. 


The project manager couldn't get Eli Goldratt’s adage of, 
‘Tell me how | will be measured and | will tell you how | 
will perform’ out of his mind. After numerous workshops, 
a suite of process measures was agreed. When the 
processes were piloted with the measures, it was pleasing 
to see that the extra time spent on unpacking these 
measures—to ensure they provided control over the 
process and provided a good measure of performance of 
the service desk agents—had paid dividends. 

Quality is not just for project managers who are ‘at 
the coal face’ of project management, wishing to have 
efficient project management processes. The success 
of project managers is also driven by the quality of the 
artefacts that are designed, developed and delivered 
into the business at the end of the project. The output for 
this project team was a carefully crafted set of processes 
and measures that enabled the quality of the processes 
outputs and outcomes to be measured, while at the same 
time allowing for measured performance of the service 
desk agents, which also promoted good team behaviours. 





reviewed and breught enbeard te impreve the preject management precesses and the preduct/service 
being preduced by the preject. In additien te the fermal decumentatien ef centinueus imprevement 
precesses, there will be eppertunities te discuss centinueus imprevement eppertunities acress varieus 
ferums, such as at preject team meetings, preject steering cemmittee meetings, supplier meetings, 
perfermance and peer reviews, epen suggestien bexes and innevatien-recegnitien pregrams. A geed 
preject manager is always interested in eliciting feedback—seeking te find eut: 


m What went well (and why)? 
m What didn't ge well (and why)? 


m What weuld we de differently next time? 


New that the basis fer quality has been established, captured and cemmunicated via the Quality 
Management Plan and ether artefacts (Swimlane diagrams), the fecus turns tewards the mere detailed 
activities ef planning quality and (later) centrelling quality. 


12.5 PLANNING FOR QUALITY ASSURANCE 
AND QUALITY CONTROL 


The PMBOK captures quality ina number of key documents. The outputs of planning quality assurance 
and quality control are often outlined in the project's Quality Management Plan, whereas the control 
of quality during project execution often manifests itself in various quality control documents such as 
run-charts, reports and checklists. 

Quality assurance criteria could already have been captured in the various project management 
documents (described in earlier chapters of this text). For example: 


Em The Requirements Traceability Matrix (see Chapter 7) has acceptance criteria against each 
individual requirement for checking the quality of the requirement meets the agreed specification 
of the requirement. 
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E Business general and business technical requirements could have been outlined in the scope 
document and/or the Business Case. 


— Business general requirements (see Chapter 7) are high-level business requirements related 
to business policies, ‘legals’, branding, cultural requirements and language. These are 
effectively quality assurance standards, against which quality must be monitored to ensure 


compliance takes place. 


— Business technical requirements (see Chapter 7) are overarching technical requirements 
related to hardware, software and interoperability. Again, these are quality assurance 
standards, against which quality must be monitored to ensure compliance takes place. 


E Story cards in a Scrum (Agile) approach (the rear of the card where ‘acceptance criteria’ are 
shown)—the quality assurance standard against which the story must be tested and later verified 
on delivery to the customer. Refer to Chapter 3. 


Table 12.5 illustrates how planning for quality assurance and quality control differs from carrying 
out quality control alone. 


Table 12.5 Planning for quality assurance and quality control versus quality control alone 


Project Management in Practice PMBOK Example: Service Industry Example: Construction Indus 
(Pearson et al.) 


Planning the quality assurance 
criteria—the standards to which 
we must ensure actual quality is 
compared. 


Planning for Quality Control—the 
activities (processes, tools and 
techniques) that will later be 
applied in the project’s Executing 
stage to control quality, thereby 
ensuring we are meeting the 
quality assurance criteria. 


Quality control: The activities of 
executing the planned processes 
(above), using the defined tools 
and techniques to measure the 
actual outputs/outcomes from 
the project and the product, 
service (or results) being built by 
the project. 


Checking for ‘variances’ between 
the planned quality assurance 
criteria and what the project 
actually produced, and taking 
appropriate action. 


Source: © 2018 Dr Neil Pearson 


Refer PMBOK p 271 
Plan quality 
management definition. 


Refer PMBOK p 271 
Manage quality 
definition. 


Refer PMBOK p 271 
Control quality 
definition. 


For the project—developing a 
comprehensive change request 
process (e.g. Chapter 7, Figure 
7.19). 


For the deliverables produced by 
the project—developing a customer 
engagement process for a new ICT 
implementation of a CRM system 
(e.g. Figure 12.4). 


For the project—checking 
(measuring) that 100% of changes 
requested to the project were put 
through the project’s formal change 
request process. 


For the deliverables produced by 
the project—verifying the process 
of customer engagements results in 
an improved customer satisfaction 
score. 


For the project—developing an 
escalation process for checking 
and validating deliveries from 
suppliers to the project (on site). 


For the deliverables produced by 
the project—developing a process 
for testing electrical fittings;, 
including how measures will take 
Place according to the electrical 
standard that has to be legally 
applied. 


For the project—checking 
(measuring) that deliveries 
received are valid and correct. 
Escalating issues to the site- 
supervisor for action with supplier 
when deliveries are not correct. 


For the deliverables produced 
by the project—measuring the 
number of electrical fittings 

that did not meet the electrical 
standards. Logging these 
variances and taking appropriate 
action to rectify faults. 


Quality assurance is the preparation of the quality aspects of the project that define the criteria, 
tolerances and processes of both the project and the product/service being produced. Quality 
assurance is about defining the standards, specifications, measures and quality control processes to 
be used, as well as stating when the quality control checks will take place and by whom. Note: We 
are only planning the quality control at this stage, not actually carrying out the processes to actively 
check the quality—this activity is discussed in a later section of this chapter. 


The authors propose that the preparation of quality assurance includes the processes of what the 
PMI terms ‘plan quality management—the process of identifying quality requirements and/or standards 


for the project and product, and documenting how the project will demonstrate compliance’—the 
last part of this statement implies the planning of quality control. Quality assurance and plan quality 
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management activities include the planning of quality control mechanisms. Some examples of what 

this may involve are: 

1. Researching, analysing and gaining agreement about the relevant quality criteria to be applied to 
the project and the product/service being produced. 

2. Ensuring the formal documentation (to a detailed level) of requisite quality assurance criteria, 
including standards, technical specifications, policies, procedures and processes. 

3. Reaching agreement and documenting how quality is to be measured, when it is to be reported, 
and what approvals must take place. 


4. Establishing any baseline measurements prior to project commencement; therefore allowing for 
measurement against this baseline during the quality control of the project later on. 


oO 


Including training and education of internal or external staff responsible for ensuring that quality 
deliverables are achieved by the project. Remember: Quality is everyone’s responsibility, but it is 
ultimately the project manager's accountability to ensure that everyone involved in the project 
adopts a quality ethos. 

6. Definition of quality governance aspects: who is responsible and accountable for all the defined 
aspects of quality? For example, state who is responsible for checking the quality of a particular 
component during a specified work package within the project, and who the issue will be 
escalated to should this measurement be out of tolerance. 

7. Compliance with any overarching quality systems which may exist within an organisation, 

for example ISO 9001:2015 (General Quality Management System Standard) or ISO 14000:2015 

(Environmental management. systems—Requirements with guidance for use). This would also 





include adoption by the project of any overarching continuous improvement processes, as 
discussed earlier in this chapter. 


Understanding quality assurance in respect to overall project quality management planning is the 
important first step. The project manager must then make sure this is taken forward and captured 
at the various levels of detail, as the project moves from the Initiating stage, through to the Planning 
stage. The Quality Management Plan clearly defines the quality assurance requirements and how 
quality control will be carried out to ensure these requirements are met. Remember that quality almost 
always impacts on other project activities, such as the project schedule, the project budget, quality- 
related risks, and the inclusion of quality specifications in procurementrelated activities (e.g. contract 
conditions). More detailed considerations to be factored into the project could include the following. 


A. Some considerations to factor into the project schedule may include: 


m Ensuring work packages include the necessary time for quality activities to be carried out. 
We know that building quality control into a task or work package is more efficient than 
checking for quality after the task has completed. 


E Defining governance and embedding this governance in all project activities to successfully 
manage quality in the project environment. We know that planning for prevention of defects is 
better than spending time on rectifying defects. 


E Adding extra work packages to carry out quality control measures and checks if required— 
we normally build quality into the work package producing the work and, if only absolutely 
necessary, checks after the work is completed. 


Em Including a ‘contingency’ to allow for continuous improvement processes to be applied within 
the project environment. Continuous improvement takes time and effort—we generally 
pursue continuous improvement requests that deliver the best value for the project. 


E Scheduling training and education programs within the project about quality; this will impact 


the availability of resources (people) that would otherwise be committed to ‘doing’ tasks on 
the project—but we know this is a worthwhile investment. 
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B. Some considerations to factor into the project budget may include: 


@ Higher costs of components. Components built to higher standards cost more money and will 
impact the final project budget—we know the level of specification is set with the customer 
and expectations that ‘What you pay for is what you get’ run true not just in projects but all 
aspects of business. 


@ Higher costs of skilled staff, or higherend service providers. Employing a major consulting 
company will cost more than a local business, but we know we are paying for topnotch 
consultants; therefore, the end result should be of higher quality. 

= Complying with companywide accreditations such as ISO 9001 will incur additional costs. 
The impact to the project must be made transparent by including additional work packages 
to cover compliance work. 


C. Some considerations to factor into the project risk may include: 
E The risks associated with nonconformance internally. Is there a risk to the project budget, 
schedule and scope if poor quality work is produced and has to be rectified? 


E The risks associated with possible damage to reputation. Will a defect reach the customer, 
what will be the risk to the organisation’s image and reputation if this occurs? 


Em The risks associated with product malfunction and harm to persons. What is the potential risk 
to the business if this occurs? 


So how can we as project managers ensure that we are taking a considerate and inclusive 
approach to the identification of the relevant. quality assurance criteria and how we plan to manage 
these in the project? A simple brainstorming techniq ue can be applied. Table 12.6 illustrates a useful 


Table 12.6 QA/QC planning grid, with examples 


Quality assurance planning Quality control planning 


What standards, technical specifications and policies are | How are the defined quality assurance attributes to be controlled? What are the 


to be applied to the management of the project and to processes, measures, tolerances and responsibilities? 
the end-product/service being created? 


Project management of the project 





Project management office (PMO), project governance Carry out project health checks at scheduled intervals within each stage of the 

requirements and project management framework. project life cycle. 

PMO gateway reviews process. Project documents presented at each gateway in the project management life 
cycle for approval, prior to proceeding to the next stage of the project. 

Harmonised with relevant workplace health and safety Health and safety audits carried out at random intervals by the internal audit 

legislation. department. Results and recommendations presented to the project steering 


committee for actioning. 


ISO/NZS/AS 31000:2009 Risk Management Framework. The corporate risk department spot-checks the project to ensure good risk 
Management practices are being applied. Results and recommendations are 
presented to the project steering committee for actioning. 


Product/service (or result) delivered by the project 


Construction example: External independent surveyor to check at the recommended stages in the laying 
Compliance with AS 2870—2011 Australian Standard® of waffle foundations. Issues to be escalated to the project manager for immediate 
Residential Slabs and Footings (https://infostore. attention. 


saiglobal.com/preview/as/as2000/2800/2870-20 11. Risk identified due to recent press reports of issues in the use of such slabs (e.g. 
pdf?sku= 1445846) https://www.cornellengineers.com.au/bewar e-waffie-slabs/} 

Service example: Random check student records post data migration to ensure compliance with the 
Compliance with the Freedom of Information Act FO! Act. 

1982 (FOI Act) (Cwlth) (https://www.oaic.gov.au/ Discrepancies to be brought to the attention of the project manager immediately 
freedom-of-information/rights-and-responsibilities) for root-cause investigation. 


Continuous improvement approach 


The project operates under a continuous improvement approach as outlined in the ISO 9001 Guidelines for the organisation. All project team 
members are reminded to apply the PDCA cycle to the project’s internal process to seek and make improvements in processes. The manager 
will need to approve all suggestions, prior to a project team member making any changes to the projects processes. 


Source: @ 2018 Dr Neil Pearson 
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way to brainstorm the initial quality criteria of both the project itself and the product/service being 
produced by the project. This tool can be used in a workshop brainstorming session to collate various 
perspectives of quality that need to be investigated through the project Initiating and Planning stages. 
Note that for each quality assurance activity listed in the left hand side of the table, there needs to be 
a corresponding quality control action planned in the right hand side of the table. 

For a further example of quality assurance and quality contro] planning and the actual monitoring 
of quality, refer to Snapshot from Practice: Apartment build. 


SNAPSHOT FROM PRACTICE Apartment build 





During a workshop on quality (hosted by the project system quality. Table 12.7 is an extract of the quality 
manager), held during the Initiating stage of a project assurance/quality control brainstorming grid in which the 
to build a low-rise five-storey block of apartments, project manager had started to capture discussions from 
discussions turned to two particular aspects of quality in the workshop. 

the project: project management quality and electrical 


Table 12.7 Planning quality assurance and quality control brainstorm grid 


Quality assurance planning Quality control planning 


What standards, technical specifications and policies areto | How are the defined quality rance attributes to be controlled 
be applied to the management of the project and to the end- |What are the processes, measures, tolerances and responsibilitie: 
product/service being created? 


Project management of the project 


Project Management Office (PMO), Project Management To ensure the PMF is being adhered to by the project, the PMO is 

Framework (PMF). to carry out random project health check assessments periodically 
throughout the life cycle of the project. 
Any deviations from the PMF will be reported back to the project 
manager within three days of the health check being carried out; 
non-compliances will be prioritised so that continuous improvements 
can be scheduled and made to the project processes in a timely 
manner. 


Compliance with relevant state/territory workplace health As detailed in the additional Workplace Health and Safety (WHS) Plan, 

and safety legislation (https://www.safeworkaustralia.gov.au/). the project office (and site environments) will be subject to all the 
requirements of the relevant workplace health and safety legislation 
as deemed necessary and overseen by the Site Safety Officer. 
The necessary control processes are to be documented in the WHS 
Plan, including the WHS reporting status, defined measures, targets, 
and tolerances, and the roles and responsibilities of the people 
involved. 


Apartment build (electrical systems) 


Compliance with AS/NZS 3000:2007 Electrical Installations Testing each fused circuit against the standard. Certificate of test(s) 

(https://www.saiglobal.com/PDFTemp/Previews/OSH/as/ by the insured registered electrical contractor (who is independent of 

as3000/3000/3000-2007 pdf). the company). Checklist of all circuits maintained and details of the 
number of ‘failed’ tests provided to the project manager on a daily 
basis, for a subsequent root-cause analysis and improvement of the 
installation processes as required. 


Product specification sheet for new low energy/low heat light Random check of light enclosure during project construction to 

enclosure. ensure compliance with the product specification sheet. Each sample 
of light enclosures tested is to be reported (in written format) to the 
site manager for a root-cause analysis and rectification actions. A 
histogram of faulty lighting enclosures is to be sent to the project 
manager on a daily basis. 





All employees of Acme Building are expected to contribute to the continuous improvement of all aspects of the project 
management process (including all tools and templates used) and must actively seek and report to the project manager quality 
improvements to the building being constructed. 


Source: @ 2018 Dr Neil Pearson 
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It is important to recognise that the quality assurance criteria against which the project quality 
control checking will take place may not yet exist in the form of standards or technical specifications 
and that these may have to be developed within the project. If this is the case, the process of integrating 
these will need to be considered carefully, given that this may result in a task (or work package) 
having to be scheduled and budgeted in the Planning stage of the project. 

Remember to draw on both internal and external resources while brainstorming the essential 
quality criteria. 

For example, internal quality assurance sources could include: 


E project management office (PMO) policies and procedures 


™ organisational project management framework and/or the standards upon which these are based 
(e.g. PMBOK, PRINCE2 and Agile) 


E gateway review processes (e.g. the OGC Gateway™ Review process (https//www.gov.uk/ 
government/publications/ogc-gateway -review-0-strategic-assessment-g uidance-an dtemplates)) 


Em internal business processes, such as procurement, recruitment, contracting and human resource 
management. 


External sources on the other hand could include: 


@ International Organization for Standardization (www.iso.org) 
m American National Standards Institute (www.ansi.org) 


m sites that offer compendiums of standards, such as SAI Global (www.saiglobal.com and www. 
standards.org.au) 


manufacturers’ product specifications 
codes of practice 


industry standards 


government legislation and policies (eften mandatery). 


This section has outlined the importance of identifying, capturing and communicating aspects of 
quality planning for the project. In the next section we'll take a look at the topic of quality control 
and examine how quality control is actually carried out in the project, how it is measured, and what 
actions may be taken, based on the outcome of the measurements. 


12.6 CARRYING OUT QUALITY CONTROL 


Moving from the identification of quality assurance criteria, to the measurement of quality once 
the project is active (typically in Executing stage) is referred to as quality centrel. (In the previous 
section we explored how the project manager has to plan both the quality assurance aspects of what 
to measure and the quality control process of hew this will be carried out in the project.) 

Quality control necessitates two key activities: 


1. Checking that the project itself is meeting quality requirements for the management of the project. 


— For example, check whether all the project approvals being obtained are in accordance with 
the project governance criteria established in the project management framework. 


2. Checking the quality of the product/service (or result) being produced by the project. 


— For example, the redesign of a braking system of a hybrid fuel cell/battery car requires 
the manufacturers to consider the additional adjusted weight of the vehicle. One of the 
components (the brake hose) therefore has to be checked at various stages in the design, 
prototype, and production stages to ensure the part meets the requirements (i.e. is within 
the tolerances specified in the technical specifications by the customer). The arising quality 
control data is plotted on a runchart and checked at the quality review meetings. 
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Quality control is often visible in the project environment due to the presence of various visual 
representations of data (e.g. charts, graphs, statistical reports). Quality control provides the project 
manager, the project team and the suppliers of products and services to the project with a method by 
which quality can be continually monitored. This enables the identification of ‘variances’ so corrective 
action can be taken. Taking corrective action (or the continuous improvement process) is key to 
controlling quality. Corrective action that is taken quickly to remedy the rootcause(s) of a problem 
may potentially ‘stave off’ future repetitions of the threat. to quality. Controlling quality starts from 
the definition and agreement of the quality specifications (quality assurance) and the quality control 
mechanisms for the project (ie. an approved Quality Management. Plan). The task of monitoring these 
defined quality requirements commences from this point onwards. From a project perspective, these 
are typically applied across all stages of the project. life cycle—from Initiating, through to Planning 
and Executing and into Closing (but more typically during the project’s Executing stage and onwards). 
The quality requirements for the product and service being produced are usually controlled during the 
Executing stage of the project, when activities start to produce project deliverables. 

A project manager should make sure they have numerous tools available to assist with the collection 
and analysis of data and subsequent presentation of quality control information. In this section we will 
review some commonly used tools that can help support a project manager to control the quality of the 
project along its many dimensions. The sample tools are drawn from many of the quality methodologies 
that were discussed earlier in this chapter, for example, Lean Six Sigma. Each tool can be used either in 
isolation or can be combined with other tools to provide further opportunities for analysis. 


SNAPSHOT FROM PRACTICE Quality control in mining 





Ensuring ore quality is maintainedis akeyconcern for mining 
operations. BHP Billiton embarked on a US$554 million 
project (completed in 2012) to shift its crushing and 
conveying facilities at its Escondida copper mine (Atacama 
Desert, 170 kilometres southeast of Antofagasta in 
northern Chile) as the quality of ore begins to deteriorate. 

Although the mine remains one of the most productive 
for the company to date, the quality of ore has fallen by 
30 per cent in the past 10 years—and a decline of this 
magnitude means only one thing: lower production rates 
and lower profits. BHP Billiton, of course, realises this and 
has announced that it is ‘studying a number of additional 
opportunities to improve access to higher grade ore and 
increase processing capacity over the years to come’ 








Shutterstock/Jason Benz Bennee 


(BHP Billiton 2011). High-grade ore is also of importance 
to share-holders, making good quality control systems 
and sampling techniques two of the top priorities for 
mining projects. 

‘Sampling’ is an important step, not just in quality 
control, but also in planning future operations. Following 
months of soil sampling and surface reconnaissance, BHP 
Billiton identified high-priority targets within its lucrative 
LluviaJojoba project. Work took place around the 
Creston Pit and a broad zone of ‘combined gold—copper 
soil geochemical anomalies’ was discovered. ‘Elevated 
gold and copper values in soil are generally considered 


to be a good proxy for identifying areas where ore-grade 
gold and copper deposits may be located sub-surface,’ 
contractor NWM said in a statement. 

Another contractor, RSV Gem, was undertaking a 
drilling phase at a goldmine 120 kilometres north of 
Harare in Zimbabwe, although it received a setback 
when previous samples were vandalised, highlighting 
the upmost importance of having clear quality control 
measures in place. Drilling also helps to confirm the 
results of earlier sampling. ‘Given the betterthan- 
expected grades at depth, the company also plans to 
drill some holes in excess of 800 metres to test this 


Continued 
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Continued 


“plunge extension”, which is open-ended,’ chief executive 
officer Vimal Bansi told Mining Weekly. He highlighted that 
the second drilling program was needed to comply with 
the South African Mineral Resources and Reserves Code 
for quality assurance and quality control assay protocol. 
Of course, quality control does not end when ore is 
sampled and confirmed, or indeed once the mineral 
leaves the mine site, as recent advancements in the area 
show. Neels Els, project manager at Dump and Dune 
Drillers, spoke to Mining Weekly about the benefits of in- 
line sampling of minerals in trucks as they are transported 
to power stations and export terminals, saying this process 
can enhance quality control processes. ‘For power 
stations, up-to-date information on the quality is important 
and can affect the operation of the stations, which is why 


Some of the more popular techniques for controlling the actual quality of the project itself or the 


we are offering this system to take samples as trucks 
or trains pass on the way to their end destination, he 
explained. 

The company's auger drill is mounted on an arm 
which takes a sample for testing from every truck that 
passes, and the company says it has also seen success 
when it has been used on coal stockpiles and discards, 
and plans on extending its use in the future. As with 
many other aspects of mining operations, automation is 
also being seen as a way of simplifying and ensuring the 
accuracy of quality control systems. 


Source: Adapted from Mining IQ Editorial, ‘Quality control in mining’, Mining 
iQ, www.miningig.com/techrical-services-and-production/articles/ Quality 
control-in-mining/, accessed January 2013. 


components of project/service (or result) being produced are described below. 


12.6.1 Run chart 


Arun chart represents some variable (data) collected over time. Taking the concept of light enclosures 
introduced in Table 12.7 (see Snapshot. from Practice: Apartment build), the project manager has 
received the information from the site supervisor as plotted in Figure 12.7. As a project manager we 


Figure 12.7 Rur 





Time Series Plot of Faults 


Summary Report 


Faults in time order 
Look for patterns and trends. 


Faults 


0 


Descriptive statistics 


N 19 
Mean 2.3684 
Standard deviation 2.2413 
Minimum 0 
Maximum 7 


With smoother 
shows general trend of data 





Day 25 01 04 
Month Feb Mar 
Year 2018 


Source: © 2018 Dr Neil Pearson 
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ure 12.8 Run chart patterns 


Saw tooth: This is where the pattern oscillates up and down frequently. 
This could be, for example, as a result of underadjusting 
an input, followed by an over-adjustment of that same input. 


Cycle: Where a repeating cycle can be identified in the data. There 
can be many causes for such a pattern, such as seasonal trends, 
shift changes, or the use of different machines. 


Run or rule of 7: Where a number (typically seven) of data points are 
outside of a ‘normal’ pattern. Again, there are many potential causes, 
but this pattern indicates that further investigation is warranted. 


Upward trending: Where over time a general increase in the 
variable being observed is identified. 


Downward trending: Where over time a general decrease in the 
variable being observed is identified. 








should be able to read charts such as this one, and be able to identify various patterns. If patterns can 
be identified, we can ask why (at the correct point in time) and initiate a root-cause analysis to find out 
what is happening. 

The run chart can help the project manager to analyse data and facilitates being able to look for 
any patterns. Some ‘typical’ patterns that are often seen in run charts are illustrated in Figure 12.8. 

In the case of Figure 12.7, perhaps the project manager should investigate what was happening on 
28 February, 7 March, and 14 and 15 March (as there is an underlying saw tooth pattern in the data). Perhaps 
the project manager could look at who was installing the fittings or which supplier the fittings were coming 
from, in order to ascertain root causes to the problem so they can put corrective actions in place. 


12.6.2 The Pareto chart (also known as the 80/20 rule) 


The Pareto chart, named after Vilfredo Pareto (an 18th century Italian statistician), is a chart that. 
contains bars and a line graph. The bars represent the categories under review (always presented in 
descending order) and the line represents the cumulative percentage total. The purpose of the chart 
is to identify where the majority of the ‘problems’ lie to enable these to be addressed first. Hence, the 
Pareto chart is also referred to as the 80/20 rule, as we are seeking to identify where potentially, 
80 per cent of problems may have occurred due to 20 per cent of their causes, in order to address them. 
We will use the data captured in Table 12.8 (in relation to the quality criteria of the lighting enclosure) 
to create an example of how this would be plotted using a Pareto chart (Figure 12.9). 


Table 12.8 Collected fault data for the lighting enclosure 





Defects of total Cumulative 
calculation calculation 
Wiring 25 55.6 (25/45) x 100 55.6 55.6 
Installation 10 22.2 (10/45) x 100 77.8 55.6 + 22.2 
Product fault 5 TIA (5/45) x 100 88.9 TSS a 
Other Si ‘lo! (5/45) x 100 100.0 88.9 + 11.1 


Total 45 
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Figure 12.9 


30 


DEFECTS 


CAUSES 
DEFECTS 
Per cent 
Cum% 


Source: © 2018 Dr Neil Pearsen 






Wiring 
25 

55.6 

55.6 


The cutoff for the categories that need to be 
investigated further is denoted at the point where the 
cumulative per cent line intersects with the 80 per cent 
line (dashed). In our example, this would include the 
cause ‘Wiring’ and the cause ‘Installation’. The chart is 
a simple but effective tool for articulating the primary 
causes of faults (as applied in this example). Further data 
could be sourced on Wiring and a nested Pareto chart 


Per cent 


created to narrow down faults within ‘Wiring’—perhaps 
en a Se eA eee Ree 40 there was one overriding fault type within ‘Wiring’? 
Once the 80 percent of problems have beenaddressed, 
a aac ca ara ae 20 the data would be collected again and plotted on a new 
Pareto chart. If the corrective actions have worked, a 
Installation Other Product fault new set of causes, again falling within the 80 per cent 
10 5 5 cutoff line, are observed. It is also not uncommon for 


22.2 111 14 > 
778 889 100.0 new causes to appear when resampling the data. 


12.6.3 Control charts 


Control charts are special types of run charts: 


The control chart is a graph used to study how a process changes over time. Data are plotted 
in time order. A control chart always has a central line for the average, an upper line for the 
upper control limit and a lower line for the lower control limit. These lines are determined 
from data. By comparing current data to these lines, you can draw conclusions about whether 
the process variation is consistent (in control) or is unpredictable (out of control, affected by 
special causes of variation) (ASQ 20186). 


In Figure 12.10, the upper of the two charts is the first part of the control chart. In this case, it 
is indicating that the process is not in contro] and producing stable results. The red data-point on 
the 6th of the month should be investigated, as it is showing what is called a ‘special cause’. The 
project manager would carry out a root-cause analysis, identifying the cause of the problem, and 
subsequently putting in place corrective actions. Note: The upper control limit and lower control 
limits are calculated from the data-points, and the UCL represents +3 standard deviations above the 
mean, and the LCL represents -3 standard deviations below the mean. (For detail on control charts, 
see https://www.isixsigma.com/tools-templates/control-charts/a-guide-to-control-charts/.) 


12.6.4 Check sheets 


Check sheets are often used to collect ad hoc data that occurs in a non-planned manner. The check 
sheet, as illustrated in Figure 12.11, facilitates the collection information in an ad hoc manner, enabling 
this to subsequently be put into other types of quality control charts (such as a Pareto chart, or a run 
chart). The check sheet is a simple tool that utilises a ‘five-bar gate’ to record counts. 


12.6.5 Checklists 


Although not a quantitative tool, checklists are useful for ensuring that tasks have been carried out, 
and are used in a variety of instances within project management. For example, Table 12.9 shows a 
project closure checklist for various human resource components for project closure. 

Checklists can also take on a more product/service focus, for example a checklist for the 
installation of a light enclosure (used in previous examples). Here, a checklist could be used both as 
a quality contro] document by the installation engineer and as a quality audit document by the site 
supervisor, who could take a random sample of the installations and run down this same checklist to 
ensure compliance had been met against each outlined step. 
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I-MR Chart of Defective Installations 
Summary Report 


Is the process mean stable? Comments 


Evaluate eeouc ute omlelpolt: The process mean may not be stable. 1 (3.6%) data point is out of 


control on the | chart. Keep in mind that you may see 0.7% 
out-of-control points by chance, even when the process is stable. 








Individual and moving range charts 
Investigate any out-of-control points. 
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= 
E 
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N: 28 Mean: 5.0714 StDev(within): 2.8894 StDevioverall): 4.4549 


Control limits are estimated using the StDev(within). 
Source: © 2018 Dr Neil Pearson 


Note: The charts in this section of the text were created using a popular Lean Six Sigma statistical package known as Minitab (wwwminitab.com/en-us/). The 
reader is encouraged to explore such tools to research how the data can potentially be visualised for prejects you are involved with. 


Table 12.9 Checklist example: for the human resources aspects of 
project closure 








Date checked | Checked by whom? | Com /ac 
Closure—human resources Light enclosure faults 


Have the team members been thanked for 
their individual contributions? 


Have the project successes been Electrical HH (| 
communicated to the various stakeholder 
groups? —— 
Have arrangements been made to release z 

Installation 
or return staff? 


Have relevant project team members 
been performance-appraised and have 


their line managers been briefed on their Wiring HHH 
performance? 


Have contractors been released, contracts 

closed-out, and procurement ‘blacklists’ 

populated with the details of any under- Other (| 
performing contractors/organisations? 


Have the project successes been 
celebrated (project closure celebrations)? 
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Benchmarking 


Benchmarking provides a reference point against which to measure. Different types of benchmarking 
exist depending on what is to be compared, including: 


E Internal benchmarks: Here, the area that is to be improved is measured before the project takes 
place. Therefore, when the project is progressing and at project completion, a benchmark of what 
was measured prior to the project’s commencement can be applied. 


E External benchmarks: With this approach, the internal data is compared against benchmark data 
from external sources. These external sources could be industry bodies or sources of information 
available in the public domain (such as annual reports and financial statements). 


m External ‘best practice’ benchmarks: A variation of external benchmarking. However, rather than 
being a straight comparison to external sources, ‘best practice’ implies structure and research. 
See for example, the PMI’s ‘maturity assessment tool’ called OPM3 (Organisational Project 

Management Maturity Model). Organisations can 

survey the maturity of project management within 

their organisations and this can be compared with 





Histogram of Calls Abandoned, Call Centre Pilot previous surveys within their organisation. It can also 


Normal be compared with best practice within the industry/ 

















35 Neel gases sector and overall, against all organisations (who 
30 x *‘*] have published) their data in the OPM3 database. 
25 
è 20 12.6.7 Histograms 
7 E Histograms are simple charts that allow the 
ue continuous data along the horizontal axis to be 
LO placed into ‘bins’ and then counted (the frequency on 
5 the vertical axis). What this tells us is how close the 
a data is to the normal distribution (as the red overlaid 
8am 12pm 4pm 8pm 12am 4am 8am line indicates). Also, reading the pattern of the data 
Time allows a project manager to move into root-cause 


Source: © 2018 Dr Neil Pearson analysis mode so they can start to ask themselves: 


Why do I see that pattern in the data? 

Figure 12.12 shows data collected from a project 
involving piloting acall centre. Time ef day is plotted 
along the horizontal axis and the frequency (or count) 





Histogram of Calls Abandoned, Call Centre Pilot of abandoned calls is plotted up the vertical axis. 
Normal 


The chart shows some unexpected high periods of 





Me 08733 ` . . 
Sibev 02466 abandoned calls. This visual representation prompts 
N 316 











the project manager to ask why this is so—and spurs 
them into carrying out a root-cause investigation. 
With some charts such as the histogram (run 
chart and box plot), it is possible to layer on the 
customers, the operational level agreement 
(OLA), or the service level agreement (SLA). 
When this is done, it becomes quite easy to see where 


Frequency 


USL i 
agreements are not being met. 


By looking at Figure 12.13, the project manager 
knows there is a problem: ultimately, the customer 





- : : : - . LSL 
8am 12pm 4pm 8pm 12am 4am 8am 

eee Coe ao N a will not sign off on the call centre until an upper 

specification limit (USL) of a maximum five calls is not 
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breached. As can be seen on the chart, the project manager has some root causes to investigate. The chart 
also indicates a lower specification limit (LSL), which has artificially been placed at the zero line, because 
there was no lower limit set by the customer—obviously, the nearer to zero the number of abandoned 
calls, the happier the customer is likely to be. (Note: The USL and LSL are specification lines set by the 
customer, net control lines (UCL and LCL) calculated from the data, as we observed in the control chart.) 


12.6.8 Bar charts 


Bar charts facilitate the comparison of frequencies (counts of) discrete categories (bins) of data. The 
categories that are being compared are placed along one axis and a measured value is shown on the other 
axis. In Figure 12.14, the project manager is monitoring the 
number (frequency) of change requests for each of the seven Figure 12.14 
types (categories) of constraints. Using this type of visual 
depiction of the data, the project. manager can monitor (and Changeineauects\by cateaornilyne 
therefore see) the categories which contain the majority of Compare the height of the bars across categories. 
change requests—in the figure this is ‘Time’. The project 

manager can then (again) take a root-cause approach 

towards questioning why this is. Once the root cause(s) have 8 
been identified, the project manager can instigate necessary 


3ar chart example 

















actions to make needed changes. (Note that a Pareto chart a © 
a 
could also have been used to visually depict this data.) a 7 
12.6.9 Box plots, or box and 2 
whisker diagrams f 
Box plots show the centre (usually the median), 25th and Scope: Tigre Cost Quality! Risk” Resource: E 
75th percentiles and the ‘whiskers’ represent the range of Change request category 
the data (the lowest to the highest value). Box plots are Total: 25 Average: 3.5714 Minimum: 0 Maximum: 10 
useful when comparisons are being made. As indicated in Source: ® 2018 Dr Neil Pearson 


Figure 12.15, two shifts on a 24-hour construction site are 
being compared. Each shift has the same task of placing ties 
on the reinforced steel bar (re-bar) to hold it in place before 
concrete is poured. The chart represents the data collected 
by the site supervisor at the end of a ‘typical’ 24-hour period. 





Boxplot of Shift A, Shift B 





The data clearly reveals that Shift A (the night shift) has Summary Report 
a far greater range in the number of faults in ties, and the Faults in re-bar ties by shift 
middle 50% of the data (the box) also has a greater range. CompareitDe a ei Cope EE 
But why? The project manager would go and see what is 25 
happening on the site with the site supervisor, as neither 3 20 i 
would want the project delayed. They would work together fa i5 
to investigate root causes, making recommendations and o 
setting followup actions for what needs to be changed. A ig 

a’ 
12.6.10 Scatter diagrams ~a ; a 
Scatter diagrams are used to visualise the correlation Shift A (Night) Shift B (Day) 
between two variables (ie. there is some relatienship Slats ESRA SMS 
between two variables). Note that this is net causation. In N S 2 e 1 E 
Figure 12.16, a project was piloting a payroll system and See PRN p 22320 
looking at different variables. The project manager noticed Maximum 23 3 
that when defects (errors) in the pay run increased, the Source:® 2618 O Nn 


number of enquiries made to the payroll department also 
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5. Measure 
and monitor 


4. 
Implement 


corrective 
actions 


Figure 12.16 





Scatterplot of Employee Pay Enquiries vs Errors in Pay Run 


Pay enquiries correlated with 


Employee pay enquiries (week) 


o 5 





errors in pay run 








Statistics Employee P Defects (E 
N 16 16 
Mean 26,75 9 
StDev 17,207 6,8313 
Minimum 6 1 
Maximum 56 21 
Fitted lines 
Linear Quadratic 
a A 

















Identify the simplest fit for your data. 
Double-click the line on the large 


graph to change the fit. 
10 15 20 


Defects (errors) in pay run 


Source: © 2018 Dr Neil Pearson 


Note: The charts in this section of the text were created using a popular Lean Six Sigma statistical package known as Minitab (www, 
minitab. com/en-us/) The reader is encouraged to explore such tools to research how the data can potentially be visualised for projects 
you are involved with. 


increased. The project manager used a variety of root-cause techniques to discover the root. cause(s) 
and implemented a change in the pilot system before the system went ‘live’. 


12.7 ROOT-CAUSE ANALYSIS 


In the previous quality control section, numerous mentions of rootcause analysis were made. This section 


investigates the process of rootcause analysis and suggests two common techniques often applied by a 
project manager in their endeavour to find the root cause or, more often, multiple causes to problems. 


1. Identify 
the 
problem 








2. Define and 
understand the 
problem 





3. Identify 
the root 
cause/s 


Root-cause analysis is often used within project environments 
to seek out the cause of a problem(s) so that this can be dealt 
with. Figure 12.17 indicates a simple root-cause process. 

A root-cause analysis involves: 


1. Identify the problem: What. specifically is occurring? (There 
are usually discernable ‘symptoms’.) 


2. Define and understand the problem: Ask initial questions 
to seek ‘proof’ (e.g. when is the problem occurring, how 
often, what is affected?). Understanding the context and the 
environment in which the problem exists is part of this step. 


3. Identify the root causes: There are numerous tools and 
techniques available. Two techniques, reviewed later in this 
section, are the ‘5 whys’ and fishbone diagrams (discussed at 
the end of this list). This step is concerned with identifying 
the root cause(s) to the defined problem. It is often the case 
that there will be a combination of (multiple) causes and 
one overriding. However, remember that there could also be 
several secondary contributing causes which also need to 
be addressed and actions put in place to rectify. 
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4. Implement corrective actions: Once the root cause(s) has been identified, corrective action(s) 
can be brainstormed and agreed upon. This may mean, for example, updating processes and work 
instructions, carrying out training, or putting additional quality control steps into a work task. 
The corrective action will depend on the problem itself and its identified root cause(s). 


5. Monitor and measure: Once corrective action(s) have been implemented, the project (or 
business) must continue to actively measure and monitor the situation, to ensure the problem 
does not reappear. It is highly likely however, given that project managers work within a culture 
of continuous improvement, that a different problem will appear, and when this occurs the cycle 
will be started once more. 


In Step 3, it was pointed out that a number of RCA tools and techniques are available and the ‘5 
whys’ and fishbone diagrams were mentioned. As promised, an explanation of these now follows. 


12.7.1 ‘5 whys’ 


Akin to a toddler’s (seemingly neverending questions of ‘but. why. . .?’) the 5 whys technique involves 
asking the question ‘why’ in the context of the last response (answer) provided to a question. Essentially, 


the proceeding question’s answer forms the basis for the next question. Figure 12.18 provides an example 
of the ‘5 whys’. 


The ‘5 whys’ 













Because customer 
doesn't understand why 


Why are we getting lots of we have change 
incorrect change requests? requests. 














The organisation has 
never tracked these in 
the past. 


Why doesn't the customer 
understand why we have 


change requests? 





Because they did 

not recognise the 

Why has the organisation never significance of change 
tracked change requests? requests. 










Because pro ject 
management was never 


Why did they not understand communicated. 


the significance? 








Because management 
had not made the effort to 


Why was it not communicated? communicate. 


Looks like the root 
cause is fast 
dropping out... 
communication! 





Note: The ‘5 whys’ is just a tag line; you may find that fe wer ‘whys’ or more commonly, more ‘whys’ are needed to get to the root 
cause of a problem. How do you know when the root cause has been reached? Typical signs are that no further value is added by 
asking another ‘why’ or the response to a ‘why’ starts to repeat (and point to) the same cause (as in this example). Another signifier of 
the root cause is when a work instruction level is reached or an environment factor around work instructions is reached, as these are 
usually at a base level in the organisation or the project. 


Source: @ 2018 Dr Neil Pearson 
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12.7.2 The cause-effect diagram (fishbone or Ishikawa diagrams) 


A fishbone (cause-effect) diagram can be used to carry out an analysis of a problem to identify its 
root. causes. Steps taken in a root cause workshop leveraging the fishbone technique could resemble the 
following: 


ne 


A problem has been identified and the project manager has defined (and now understands) the 
problem. The project manager recognises that containment actions may need to be put in place as 
a temporary stop-gap. 

The project manager puts together a brainstorming team that includes members of the project 
team, subject matter experts and an external consultant. The project manager sets out the 
fishbone method at the brainstorming workshop and encourages participants to use this as a way 
to brainstorm the root causes of the problem. 


The project manager draws up the large bones on the fish and labels them: 


a. Manpower/mind power 

b. Machine (tools and technology) 
c. Method (the process) 

d. Materials 

e. Measurement 

f. Mother nature 

g. Management 

h. Maintenance 

iL, 

Leaving a ‘?’ (question mark) indicates that other categories might emerge during brainstorming 
and these can be added. 


Table 12.10 Cause and effect brainstorming categories 


8 Ms of manufacturing 8 Ps of marketing 3 CPOs of service 

Manpower/mind power Product/service Culture 

Machine {tools and technology) Price Communication 

Method (the process) Promotion Customer 

Materials Place People 

Measurement Process Process 

Mother nature People Politics 

Management Physical evidence Organisation 

Maintenance Performance Objectives 
Operations 

4. The project manager hands a pack of ‘sticky notes’ to each brainstorming session attendee and 


on 


asks them to write down every potential cause of the problem they can think of (from every 
conceivable different angle). After two hours the team is exhausted, but is pleased by the large 
number of potential ‘causes’ they have brainstormed. (Refer to Figure 12.19.) 


Next, the project manager summarises and clarifies the suggested causes with the team. After this, 
the project manager allocates the large bones on the fish (the suggested potential causes) to each 
member of the project team, asking them to report back tomorrow morning with facts/evidence/ 
data that proves the item brainstormed is not a cause of the problem. This continues for a couple of 
days. 
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6. By midweek, the project team members are leaning 
towards three potential causes as being the root 
cause(s) of the problem. These suggestions are 
investigated by going and seeing and indeed, prove to 
be the very root causes! 


7. Improvement actions are agreed upon, the process 
is improved, the work instructions are updated and 
further training is carried out. 


8. The project manager comes back a week later to 
measure and check that improvements have indeed 
cured the problem. 


The cause-effect diagram forms a powerful tool for 
‘group thinking’ around why a problem is occurring. 
Depending on the severity of the problem being 
investigated, the project manager may consider halting 
related tasks, until the root cause of the problem has been 
identified and mechanisms have been put in place to rectify 
the process. Once the problem has been identified and dealt 
with, tasks can resume. 





Source: ® 2018 Dr Neil Pearson. 


The ‘5 whys’ and fishbone techniques can be applied in a process of root-cause analysis (see 
Figure 12.2@) beyond the realms of investigations into exploring issues about quality. These techniques 
are useful at any peint where a root cause needs to be identified. 


Figure 12.20 Cat 








Inadequate Process not 
tools followed 
Faulty testing Inadequate 
equipment tools 


Training in use 
of tools and 
testing 
equipment 


Installers 
certified? 





Wiring, faults in 
the installation 
of the light 


Never enclosures 
Low quality Poor lighting Misra 
the process 


Not meeting 
AS/NZS 














Rushed, piece 


standard work pay) 


Source: © 2018 Dr Neil Pearson 
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12.8 SCRUM (AGILE) CONSIDERATIONS 


Each story card in a Scrum (Agile) approach has ‘acceptance criteria’ documented on the back of it 
showing the quality assurance standard against which the story must be verified during testing of 
the story (after its development within the sprint). Acceptance criteria can also be demonstrated on 
delivery of the ‘potentially shippable release’ to the customer, to demonstrate that it meets the criteria 
that was agreed and captured on the story card. 

The sprint retrospective also has a quality aspect to it, as it involves seeking lessons-learned 
about the process, tools and techniques used within the sprint. Once a lesson has been identified, its 
root cause(s) are investigated and an improvement is put in place (preferably before the start of the 
next sprint). 


Quality is everyone's responsibility and therefore ensuring that clear quality criteria are established, both from a 
project management perspective and a final product/service perspective, is critical. The project manager is ultimately 
responsible for ensuring that definitions of quality are articulated, documented, agreed, actioned and achieved by 
applying the processes, tools and techniques outlined in this chapter. This chapter has introduced the concepts of: 

m Ensuring an environment and culture of continuous improvement is promoted in the project environment—to 
continually learn from and adjust (improve) processes and systems that govern how the project is measured. 

m Articulating assurance standards (specifications) against which the product/service or results will be measured, in 
order to gain sign-off of the project. 

m Managing (or controlling) quality throughout the project life cycle; particularly during the project Executing stage. By 
using visual representations of data, the project manager can identify where problems exist and work to identify their 
root cause(s). 

m Carrying out root-cause analysis as a matter of routine work to ensure time is spent on the ‘right’ things. The project 


manager can use the ‘5 whys’ and the fishbone technique to gain group involvement and participation when seeking 
out the ‘true’ root causes to a problem. 


The project manager is responsible for ensuring perceptions of quality, as viewed by the key stakeholders in the 
project (the sponsors, customers and suppliers), are captured as tangible, agreed and measureable quality criteria. 
This can be a challenging endeavour to undertake. However, if perceptions are left unarticulated and undefined, this 
will undoubtedly lead the project down a disorderly path of troublesome issues. The adage ‘fit for purpose’ does not 
define quality, but merely indicates a perspective as seen from an individual viewpoint. It is the project manager and 
project team’s responsibility therefore to ensure that relevant, measurable quality criteria are established at the outset 
of the project. Quality needs to be taken on board as being every project member's responsibility and needs to be 
controlled effectively throughout the Executing stage of the project. 


www.ansi.org 
www.asqa.gov.au/about-asqa/national-vet-regulation/vet-Quality-framework.html 
www.Iso.org 

www.lean.org/WhatsLean/ 

www.omg.org/spec/BPMN/2.0/ 

www.saiglobal.com 

www.standards.org.au 

www.bpmb.de/images/BPMN 2_0_Poster_EN.pdf 
https://www.iso.org/iso-9001-quality-management.html 
https://www.iso.org/standard/60857.html 
https://www.iso.org/standard/43170.html 
https://www.gov.uk/government/publications/ogc-gateway-review-0-strategic-assessment-guidance-and-templates 
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‘5 whys’ cost of quality (CoQ) quality assurance 

80/20 rule fishbone (cause-effect) diagram quality control 

bar chart flowchart Quality Management Plan 

benchmarking histogram root-cause analysis 

box plot, or box and whisker plot ISO 9001 run chart 

business process model and notation Lean service level agreement (SLA) 
(BPMN) Lean Six Sigma Six Sigma 

check sheet operational level agreement (OLA) Swimlane diagram 

checklists Pareto chart total quality management (TQM) 

control chart Plan, Do, Check, Act (PDCA) unified modelling language (UML) 

cost of poor quality (CoPQ) processes voice of the customer (VoC) 


Review questions 


awune 


onan 


Why is the definition of quality critical to the success and acceptance of a project? 
What is the difference between quality assurance and quality control? 
What would the QA/QC planning grid (see Figure 12.6) look like for a project you have been involved in? 


What quality systems and standards exist in your organisation to 1) ensure quality across the project and 2) ensure 
quality within the products and services produced by your projects? 


What is the purpose of the Quality Management Plan? 

Which types of tools would be useful for investigating the root cause of a problem? 
How cana run chart be used within a project environment? 

Explain the process of developing a fishbone diagram. 


= 


BN 


= 


Using the quality criteria grid from Figure 12.6, brainstorm key dimensions of quality that are applicable to a project 
you are currently managing. In doing so, remember to focus on clarifying ‘perceptions’ of quality (i.e. ‘fit for purpose’ to 
tangible criteria of quality). 

Using your response to Exercise 1, select one of the high-level quality criteria you identified and apply this to the grid in 
Figure 12.6 to provide depth of understanding about the criteria, and how the criteria will be measured and controlled. 
Apply the fishbone technique to a problem you have recently encountered and then comment on what this technique 
reveals. 

Thinking about a specific area of a project you have worked on, reflect back on ‘Carrying out quality control’ in section 
12.6 of this chapter and think about what should have been measured and controlled through the use of data 
visualisations introduced. 
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CHAPTER 13 
PROJECT RESOURCE MANAGEMENT 





Learning elements | 


413A Be able to successfully identify the resources required to accomplish a project. 


13B Understand the planning aspects of project resource management, including the 
Resource Management Plan. 


130C Understand the process of resource identification, resource estimation, acquiring 
resources, monitoring resources and releasing resources. 


43D Understand the links between resources, schedules and estimating. 


43 Gain an understanding of how to monitor and control project resources and avoid 
some common pitfalls. 














In this chapter 


13.1 Introduction 
Ææ 13.2 What are resources? 
13.3 The Resource Management Plan 
lm 13.4 Resource identification 
13.5 Acquiring resources 
13.6 Monitoring and controlling resources 


13.7 Scrum (Agile) considerations 





Summary 
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13.1 INTRODUCTION 


In this chapter, we will review some of the more practical aspects involved in identifying resources, 
planning resources and managing the practicalities of resource commitments. Note that Chapter 14 
contains a lot of information on the ‘softer aspects’ of human resource management, including team 
building, codes of ethics, leadership and managing project teams. This chapter focuses on the Project 
Management Institute’s (PMI) updated understanding of what a ‘resource’ is and discusses some of the 
tools and techniques available for planning and controlling how resources are applied to the project. 
Figure 13.1 represents the cycle of resource management discussed in this chapter. 

The project manager experiences the iterative nature of this cycle, especially during the Executing 
stage of the project, where resources are continually loaded into the project. It is for this reason that 
some projects assign dedicated ‘project schedulers’ to the project: to maintain the project schedule, 
carry out resource allocations, manage resource allocations (e.g. conflicts), monitor the results of 
work packages and prepare reports for consideration by the project manager. 


13.2 WHAT ARE RESOURCES? 


The PMI, in the sixth edition of A Guide to the Project Management Body of Knowledge (PMBOK®) 
(PMI 2017) has widened its definition of ‘resource’ to formally encompass not just ‘human’ resources 
but all resources required by a project. Of course, project managers have been considering the wider 
implications of ‘all resources required by the project (human and other)’ for some time now. Refer 
back to Table 8.2 Typical types of resources utilised by projects, which deliberately aims to challenge 
and widen project managers’ thinking about what a resource may look like in a project. This chapter 
extends this thinking and therefore necessarily encompasses both human and all other resource types 
throughout its narrative. 

Note: The resource types in Table 8.2 may possibly relate to the way your organisation accounts 
for resources within its financial, procurement (and other company) policies. It would therefore be 
worth checking with the organisation’s relevant departments whether it already has a list of stated 


1 The resourc 


Resources 
identified and 
estimated 
© Resource matrix 


Resources 
scheduled 
e Project schedule 


Resources 
release/disposal 


Resources Resources 
remunerated acquired 

* Contracts * Resource matrix 
e Project budget * BoM 


Resources 
monitored 





* Project reporting 
e Project schedule 





Source: © 2018 Dr Neil Pearson 
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resource categories so you, as project manager, can then leverage this in activities such as ‘resource 
identification’ (discussed later in this chapter). 


13.3 THE RESOURCE MANAGEMENT PLAN 


When considering project resource management, we need to consider how resources are going to be 
planned and managed. A Resource Management Plan (one of the subsidiary plans to the Project 
Management Plan) is therefore used to accomplish this. 

The Resource Management Plan encapsulates the legislation, policy and procedure, best practice 
and governance (among other items) that is involved in the management of resources. The plan is 
supported by a number of other documents, such as the Skills Matrix, the Resource Allocation Matrix, 
the RASCI Matrix (refer to Chapter 14, section 14.9.3 ‘Ensuring clarity of roles and responsibilities’), 
the Bill of material (BoM), the work breakdown structure (WBS) and the project schedule. Typical 
contents of the Resource Management Plan are outlined below. 


E Resource strategy and approach: This initial section of the Resource Management Plan describes 
the general strategy and approach taken towards human resources management within the 
project. For example, it might set out whether the use of contractors is preferred or whether 
the project will ‘second’ resources from the business. Secondment is the temporary lending of 
resources from a department into the project; on completion of the project, the resources are 
typically returned to the department. Remember that seconding resources to the project may 
generate an indirect bonus if personnel gain additional skills and knowledge and subsequently 
take this back into the business/their substantive role when the project is closed and they are 
released. The plan sets the tone of the project and indicates the preferred management approach 
towards acquiring resources for the project. 


Policy and procedure: This identifies any relevant organisational resource-related policy and 
procedure that has to be applied within the project environment. Typical organisational process 
assets the project may need to adopt can include: 


— Human resources: 

m recruitment policy and procedure 
performance management guidelines 
training and development guidelines 
staff release policy and procedure 


contract policy and procedure affecting the recruitment of human resources 


references to pay scales 

E details of union negotiated enterprise bargaining agreements (EBAs) or other union agreements. 
— Other resources: 

E asset management policies 

m maintenance policies 

m facilities policies. 


E Project organisational structure: Although the project organisational structure is typically 
illustrated in the project scope document, it is not uncommon to also see the structure 
documented within the Resource Management Plan, supported by a more in-depth discussion on 
team dynamics, organisational] culture and roles. Although the Resource Matrix captures all of 
the required dynamics of the resources, the project manager may also want to have a ‘snapshot 
view’ of key resources available to them. See Tables 13.14 and 13.1B. 
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Table 134A Examples of key human resources 


[Roe O Description More information 


Project administrator Provides administration support to the project, including Refer to role description: ‘Project Administrator’. 
document management, financial status reporting and 
other reporting, as specified in role description. 


Contracts manager Develops, reviews and manages all contractual Refer role description: ‘Contracts Manager’. 
arrangements for any contract identified in the project. 


Table 13.1B Examples of other key resources 


Description Further information 


Corporate file server The corporate file server is evaluated to ensure that it is Refer to: Service Request SR-76534 (logged with a 
capable of storing the large volumes of project information Service Desk). 
that will be generated and to ensure data can be 
accessed, updated, searched and extracted expediently. 


Back hoe machinery Required in the ‘foundations’ work package. Contact the site preparation department to undertake 
a resource availability check. 


m Governance (roles and responsibilities): As with management plans introduced in previous 
chapters, use the RASCI Matrix early in the project to ensure that resource-related business 
rules and/or decisions are clearly articulated and implemented. The human resources component. 
of the RASCI typically enables miscellaneous HR actions to be defined and captured, for example 
regarding what is to occur if conflict situations arise, or what happens if role clarity needs to be 
achieved. An example of a simple RASCI is included as Table 13.2. 


Table 13.2 RASCI Matrix 





Ref. Business rule/ Category Role 
decision 
Sponsor | Project Project Project Project | Organisational Finance 
manager support | steering team HR manager and payroll 
committee department 
ils Approval of any Resource — HR R R A | Cc | 
HR resource to the 
project. 
14. Ensuring project Resource—HR A R R 
induction has taken 
Place. 
16. Ensuring server Resource—other | AR Cc 


Capacity is available 
to the project. 


E Recognition and reward: Aim to set out a clear and transparent reward system for the project 
team (as a group), plus details of any individual reward arrangements—remember to ensure 
arrangements are in line with company policy and procedure. 


E Project team agreement: If necessary, establish a project team agreement. This may contain the 
project’s logo and values, be signed by all project team members, and be displayed in a prominent 
place within the project environment. 


Em Risk review: Ensure a risk review of resource activities is carried out and that any risks identified 
are captured in the project’s Risk Register under the category of, for example, ‘Resource—other’ 
or ‘Resource—HR’. 
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E Lessons-learned: Ensure that a review of any lessons learned from prior similar projects is 
undertaken, and that any relevant lessons-learned are entered into the project's LessonsLearned 
Register under the category of ‘Resource—other' or ‘Resource—HR’. 


E Assumptions and constraints: Consider what assumptions are being made in relation to 
resources for the project (remember an assumption is an assumed statement of truth). Also, 
capture any resource factors that may constrain the project, for example, a particular skills 
shortage, or getting access to a particular piece of equipment. The project manager should 
also be cognisant of the way in which marketplace conditions may inform assumptions and 
constraints (and even risks). 


E Team Development Plan: Outline the approach to be taken towards team development. This 
could range from planned team-building activities, to aspects of how the project team is going 
to function across a global virtual team environment. Note that there may be both schedule and 
budgetary implications, which may not have been identified through the development. of the work 
packages within the WBS. 


Source: © 2018 Dr Neil Pearson 


As with all management plans, although it is important to document resource dynamics, the 
actual ‘value’ aspects of these typically emanate from discussions, consultations and decisions that 
have collectively produced an agreed set of statements that can be communicated to all members 
of the project team. Such analysis undoubtedly opens up other questions, which may, for example, 
result in a risk being raised, a new task being added into the WBS, a change being made to a work 
package, a change to a lead/lag time on a task in the schedule, and an additional cost to be included 
in the project budget. 

If the Resource Management Plan has been created as an Integrated Resource Management Plan, 
it is likely the information on human and other resources will be integrated together in a single plan. 


More commonly, two distinct plans are developed, one covering human resources and the second 
covering other (physical) resources, as illustrated in Figure 13.2. 


Figure 13.2 Int act haman other res 








[PROJECT NAME] [PROJECT NAME] [PROJECT NAME] 
Integrated Resource Human Resource Other (Physical} 


Management Plan Management Plan Resource 
af Management Plan 




















Integrated OR Separate human, and other 


Source: © 2018 Dr Neil Pearsen 
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13.4 RESOURCE IDENTIFICATION 


A comprehensive identification of the resources needed by a project is an essential element of any 
project, and a project manager (assisted by the project team) can use a variety of techniques to help 
them identify required resources. Three techniques often applied by the authors for doing this are: 


1. Developing a resource breakdown structure (RBS). 
2. Leveraging the work breakdown structure (WBS). 


3. Reviewing lessons-learned from previous projects. 


These approaches are discussed below. 


13.4.1 Resource breakdown structure 


A resource breakdown structure (RBS), much like a WBS, is a hierarchical decomposition, but the 
RBS is a decomposition of resource categories. When an RBS is being developed, it is important to 
involve project team members (and other stakeholders, as appropriate) in the process, so as to ensure 
differing perspectives are tabled for consideration. Development of the initial RBS usually involves a 
brainstorming workshop (using Post4t® notes), to draw out all the potential resources that will be 
required to achieve the project. Figure 13.3 illustrates an RBS for part of the ‘house build’ example 
introduced in Chapter 7 and used in previous chapters. Captured here in a PowerPoint format are the 
results of the brainstorming workshop with SMEs and project team members. 

There are some advantages to brainstorming in this manner, as this approach allows a less structured 
methodology and inspires more ‘creative doors’ to be opened. This hopefully increases opportunities 
for identifying resource items that have not previously been considered. Also, by inviting the right 
stakeholders along to participate, the project manager should be able to leverage the opportunity; 


using it as part of the stakeholder engagement strategy by engaging with stakeholders face to face. 


Figure 13.3 Example rce breakdown structure (R. house buil: 


+- 





House build 
(3 bedrooms plus 
garage) 







Shutter boards 
and stakes 





Source: © 2018 Dr Neil Pearsen 
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13.4.2 Leverage the work breakdown structure (WBS) 


Leveraging the WBS can be carried out in a bottom-up or top-down approach. 


E As a bottom-up approach: The WBS (at the work package or task level) provides an ideal 
opportunity to collect detailed resource requirements. This approach is ideal when in the Planning 
stage of the project life cycle. Figure 13.4 illustrates this, based on the house build project. 


E Asa top-down approach: The project manager can allocate resources from a top-down (higher 
level) perspective. This approach is ideal for identifying the key resources (human and other) 
required by the project when in the Initiating stage of the project life cycle. For example, 
resource commitments at the higher-level ‘deliverable’ or ‘control packages’ in the WBS could 
be made. 


The WBS, or Bill of Materials (BoM), might also capture decisions about how resources will be aquired 
into the project. (See also Snapshot from Practice: Defining a WBS and identification of resources.) 

If, for example, a WBS deliverable-level item was tagged as being an ‘outsourced’ component (from 
a previous make or buy analysis), then the project manager would not be advised to make an estimate 


Resource identification and estimati n 


WBS/work package Resource type Source Arrangement Estimate basis 





~. Plans and approvals 








°, Foundations 
2.1 Survey and stake-out site 
Surveyor Surveyor Internal Cross-charge to the project| $1000/day 














2.2 Prepare foundations 
2.2.1 Excavate 
Backhoe Equipment Hire Preferred supplier. Hire $1000/day 











Backhoe operator Labour Internal Cross-charge to the project | $500/day 








2.2.2 Lay re-bar 
General labourer #1 Labour Internal Cross-charge to the project | $200/day 
General labourer #2 Labour Internal Cross-charge to the project | $150/day 




















Steel reinforcement bar Materials Purchase | Preferred supplier. 





Bar posts and ties Materials Purchase | Preferred supplier. 





Cross-charge to the project| $1000/day 








2.2.3 Survey check | 
Surveyor Labour | 


Internal 








2.3 Pour concrete 
Concrete 60 cubic metres Materials Purchase | Preferred supplier. Based on 








General labourer #1 Labour | Internal | Cross-charge to the project | $200/day 
General labourer #2 Labour | Internal | Cross-charge to the project | $150/day 

















. Frame, walls and roof... 


Source: © 2018 Dr Neil Pearsen 
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SNAPSHOT FROM PRACTICE Defining a WBS and identification of resources 





On a recent project, one of the authors (Pearson) worked 7. 
with an outside consulting company to define a repeatable 
WBS structure against which resource types could be 8. 
allocated. This project started off by clearly identifying the 
top-level deliverables of the project, resulting in 11 modules 
of a software redevelopment project. 

For each of these 11 modules, a repeatable approach 
was taken to the high-level work packages that had to be 
achieved. These high-level work packages included: 


Development of the schedule to build the required 
artefacts. 
Implementation considerations for the ‘to-be’ design. 


These repeatable work packages were applied 
to each of the 11 modules. Subsequently, the project 
manager and consultants were able to carry out a high- 
level identification of the resources required to complete 
each work package. 

Although this activity took some weeks to complete, 


ibs 


Development capture of ‘as-is’ process for the 
application area. 


at the end of the exercise a total high-level resourcing of 
the 11 modules, and therefore the project cost, could be 


2. Assessment and prioritisation of future requirements obtained. This informed the Business Case and scoping 
of the application area. of the project in its Initiating stage and enabled better 

3. Gap analysis of the ‘as-is’ process to the high-priority management decisions to be made on the affordability 
requirements identified. of, and therefore the approach to be taken to, the 

4. Assessment of impact to the technology, people and subsequent design of the project, before proceeding 
structure of the organisation. into the Planning stage of the project. 

5. Definition (design) of the ‘to-be’ in terms of process, 


people, organisations, information and technology 


Source: Pearson N 2012, A university clearing house software 


requirements. redevelopment project 


6. Design of the epics, increments and sprints from this 
resulting design (per point 5). 


of this resource requirement for this deliverable-level item. If the project decision has been made to 
outsource and information is required on exactly what resources will be supplied, then an initial request 
for information (RFD, or even request for quotation (RFQ) can be obtained. The project manager can then 
review these proposal responses and carry out.a ‘map and gap’ between what the supplier is stating would 
be provided in terms of resources, and what additional resources may be required to be supplied by the 
project. Simple techniques such as the map and gap provide clarity and reduce the need for assumptions. 


13.4.3 Lessons-learned and previous projects 


Although leveraging lessonslearned can be very helpful to project managers, this opportunity is (quite 
surprisingly) sometimes overlooked. Taking a lessons-learned approach towards resource management 
simply means looking at previous, similar projects to learn valuable lessons about resources. 

Using these three techniques, the project manager (in conjunction with the project team and other 
stakeholders) should be able to carry out a comprehensive prospective resource identification for the 
project. 


13.4.4 Using the RAM to validate resources 


Another technique often used to validate resources have been identified is the Responsibility 
Assignment Matrix or the Resource Allocation Matrix (RAM). It is most often presented as a hybrid 
WBS and RASCI Matrix. Figure 13.5 illustrates a RAM for the house build example. 

The RAM indicates who (which role in the project) is accountable, responsible, consulted, informed 
or supports each of the work packages in the WBS. In building the RAM, the project manager and 
project team have to think hard about. what resources would be required. 
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Figure 13.5 E: 
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13.4.5 Capturing further human resource information 


The capturing and analysis of project team roles at this stage is vital. Most project managers will 
maintain an alkencompassing Skills Matrix collating details of resource requirements for each work 
package. Additional information for human resources could include: 


E Reseurce/skills identificatien: Required skills are identified against each WBS item/work package 
(as are the resource loading, cost and duration for the required resource). This component of the 
matrix is typically populated during the development of the WBS and the estimating activities of 
the project (during the Initiating or Planning stage of the project life cycle). Refer to Table 13.3. 


E Staffing management infermatien: This section of the matrix should indicate the sources of the 
resources and whether these are to be obtained from within the organisation or externally. How 
a resource is to be released upon project completion should also be addressed. For contracted 
resources this is an easy task. However, for internal resources that have been seconded to the 
project from the business, there may be a number of stages that have to occur in order to move 
the resource back to its substantive position in the business. Refer to Table 13.4. 


E Training needs analysis (TNA): This section aims to identify qualifications, certifications 
(trade or professional) and insurances that may be required. An analysis should be undertaken to 
identify any gaps in training, as these might have implications for the project in terms of training 
that needs to be provided, and the associated cost(s) and schedule implications of this. For 
example, if we require ‘trades’ on the project to carry out electrical testing, then not only would 
they need relevant qualifications, but also current industry/government body certification(s). If 
their certification(s) were to expire during project execution, this could place the project in an 
awkward situation. Refer to Table 13.5. 


E Performance management: This section shows how an individual will be performance managed 
within the project environment. Questions should be asked around: What. key performance 
indicators (KPIs) are to be set? What targets are to be achieved? Refer to Table 13.6. 


This list could also be adapted for other resource types. 
Although the task of building and maintaining this level of information may, at first, seem excessive, 
the reality is that given the vast potential for delays in activities to occur and for money to be ‘burned’ 
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Table 13.3 Resource identification information 


Work package 


Resource category 


Resource skills 


Resource name(s) 
Project stage 
Resource loading 


Estimated resource usage percentage 


Estimated duration required 


Resource calendar 


Source: @ 2018 Dr Neil Pearson 


Alink to the WBS, where the resource was identified. 


Acategory for the resource—such as tester, developer, electrician. This is useful for when the project 
Manager wishes to look at the total requirements of a resource category, across the whole project. 
Decisions can then be made on how to source this resource to the project (e.g. fulltime versus 
contracted when needed). 


The skills the resource needs to have. These could, for example, range from specific skills (such as 
Visual NET programming skills, to ‘softer’ skills such as change management skills). 


Actual resource ‘name’ if known at this time. 
State in which stage of the project the resource is primarily going to be deployed. 


Is the resource ‘front-loaded’ (used heavily at the start of the project/stage), ‘backloaded’ (used 
heavily at the end of the project/stage) or ‘normally loaded’ (an even usage of the resource 
throughout the whole stage/project)? 


Estimated usage of the resource—obtained via the estimating activities carried out in the Initiating 
and Planning stages of the project. 


In real terms, how long is the resource required for (i.e. number of hours/days/weeks/months)? 


Is the resource available for a standard working week, or is the resource only available on certain 
days of the week? 


Table 13.4 Staffing management information 


Internal resource source 


External resource source 


Resource acquisition strategy 


Resource funding 


Estimated cost 


Extension considerations 


Release strategy 


Source: @ 2018 Dr Neil Pearson 


Is the resource to be sourced internally and if so, from where within the organisation? Refer to 
Chapter 5. 


If the resource is to be sourced externally, which agency or company may be able to provide the 
resource? 


How will the project manager bring this resource into the project? Will the resource be subject to special 
approvals? Does the project manager have to go through (sometimes a lengthy) internal recruitment 
process (as documented in the organisation's internal recruitment policies and procedures)? 


How is the resource to be funded—directly to the project budget, to be internally cross-charged or 
will the resource be covered in company overheads? 


What are the estimated costs of the resource? Is there a day rate arrangement, or a standard rate 
arrangement of cross-charging for internal resources? 


If use of the resource needs to be extended, what associated considerations will the project need 
to include? If use of the resource is extended, does the rate change, for example? Is a retainer fee 
appropriate to keep the resource on the project’s books? 


What considerations have to be put in place when the resource is released from the project? For 
example, if the resource (a person) was seconded from within the organisation and their position in 
the business has been back¢illed by another person, will this mean the project manager will have 
two resources to make arrangements for? As release considerations can be complex, the project 
Manager should consider the release strategy at the point when the resource is identified, thereby 
setting the expectations and hopefully a smooth transition of resources from the project when they 
are no longer required. 


Table 13.5 Training needs analysis (TNA) 


Required certifications 


Expiration date 


Required qualifications 


Training gaps 


What certifications must the resource have, from a legal and compliance perspective? For example, an 
electrical tester must hold certifications from state/territory or regulatory bodies in order to practise. 
Identify what these are and check that these are valid for the duration of the activities they have been 
assigned to. 


Arecord of when these certifications are due to expire. 


What qualifications must the resource hold? For example, is a degree in electrical engineering 
required? 


Given that resources with the necessary skills, certifications and qualifications may not be readily 
available, how will these be obtained from the project environment? There may be integrative 
implications to the project schedule (e.g. downtime of the resource while the resource is trained) and/ 
or a cost implication (e.g. the cost of training or certification), which has to be included within the 
project budget. 
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Insurances/company reg./ The project manager must ensure that the company, contractor or consultant holds current and 

visa requirements relevant insurances (some of these may have been reviewed as part of procurement activities). If a 
resource is being brought in from overseas, have appropriate checks been made to ensure they hold 
a relevant work visa? 


Employment status The location of the resource within the recruitment process needs to be ‘tracked’ to check whether 
they are progressing through the process on schedule, so they can join the project at the right time. 
Recruitment processes are notorious for not going according to plan! For example, if no suitable 
personnel are identified in initial recruitment interviews, delays will ensue as a consequence. Role(s) 
will have to be readvertised, new applications sifted through, and interviews organised and held for a 
second group of candidates. 


Company induction What company inductions does the resource have to progress through? Are the induction programs 
in line with the project schedule or does the project need to make special arrangements with the HR 
department? 

Project induction Has the resource been suitably inducted into the project environment? (It is not unusual to have a 


project induction program for medium to large projects.) 





Source: © 2018 Dr Neil Pearson 


Table 13.6 Performance management information 


Performance management How is the resource to be performance managed? If the resource was recruited directly to the 

arrangements project, it would be the project manager’s responsibility to put in place the necessary performance 
management schedules. If however, the resource already reports to a line manager in the business 
as their functional manager, what arrangements will be put in place (with the line manager) to 
performance manage them? 


KPIs and targets A project manager should define a set of key performance indicators (KPIs) and targets that have to 
be achieved by the resource. These may, or may not, be linked to performance payments or bonuses. 

Achievement (tracked during the Performance should be tracked for each resource on an ongoing basis, as this makes being able 

project and at project closure) to make any recommendations at the end of the project easier (e.g. when deciding whether to 


recommend bonus payments, if any are available). 


Source: © 2018 Dr Neil Pearson 


unnecessarily in the project, taking the time to prepare and maintain this type of information can 
actually pay great dividends in the long term. 

After reviewing the skills that are needed in the project, the project manager should try to find out 
through the corporate grapevine who is suitable, who is available, and who might want to work on the 
project. Some organisations may allow personnel to be invited for direct interviews. Often, a manager will 
have to use political capital to try to get highly skilled (in high demand) personnel assigned to their project. 

If operating within a matrix environment, then the project manager will have to request 
appointments with functienal managers to discuss project requirements for staffing. In this case, 
the following documents should be made available for discussions: project scope statement, project 
endorsements from top management, description of the tasks their staff will be required to perform 
and the schedule of when the resources will be required. Project managers need to be precise about 
what resources they are seeking and why these are important to the project. 

Functional managers should be encouraged to suggest the names of people within their departments 
who are potentially suitable candidates. If the project manager is asked to suggest the name of a 
potential, suitable candidate, it might be wise to say something along the lines of: ‘Well, I would really 
like [Pegi Young], but I know how critical her work is so how about [Billy Talbot?]’ If the conversation 
goes this way, the project manager may be able to cut a deal then and there. If so, they will need to put 
the agreement in writing immediately after the meeting as a memerandum ef understanding. If, onthe 
other hand, the functional manager baulks at their suggestions and the meeting does not progress as 
hoped, then the project manager should nimbly terminate the conversation with a clear understanding 
that the matter will be discussed again in a few days. This technique demonstrates persistence, and a 
desire to do what it takes to resolve the issue. Ultimately, of course, the project manager will have to 
settle on the best offer available. Managers should exercise care not to reveal how different members of 
the team were selected. The project might be crippled from the outset if reluctantly assigned members 
are identified, and the team then perceives potential differences in attitude and commitment levels. 
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13.5 ACQUIRING RESOURCES 


One the resources have been identified, estimated and linked to the project schedule—that is, the 
project manager not only knows what resources are required, how much the resources will cost 
and when those resources will be required—the project can next take steps towards acquiring these 
required resources. (Note: The how much discussion is tackled in Chapter 8 and the when component 
is covered in Chapter 9). 

The project manager should be in a position to negotiate resources from those able to provide 
resources to the project. If the project manager cannot successfully negotiate resources, it can fall 
to the project sponsor to do this on the project manager’s behalf (PMI, 2017). On paper this sounds 
simple, but the act of acquiring resources can be fraught with challenges that can affect the planning 
of the project. For example: 


E Organisational politics kick in: Executives and managers play a political game to retain 
resources on lowerpriority projects because giving up resources might indicate to others 
that work in their department is slow at. the moment, or they strategise to retain their staff 
headcount, which they perceive as influencing their power in the organisation. Unfortunately, 
these types of activities are still commonplace in a lot of organisations (whether commercial, 
government or other). 


E A resource is withdrawn: A department or function might suddenly withdraw resources at 
short notice (Murphy ’s Law states this will occur just before the Executing stage!) This could 
be in response to any number of situations, but typically is due to fire-fighting a crisis in the 
operational side of the business. 


E The business re-organises due to changes in market conditions: This should not be a surprise but. 
if it does occur during the project, it could cause substantial resource issues. 


@ There are restrictions to resources from the outset: 
— The project manager typically does not have direct control over the resources required. 


— The resources could be subject to union, enterprise or collective bargaining arrangements, and 
therefore cannot be released from business as usual activities. 


— The resources could be ina supply and demand relationship where others (project and companies) 
with deeper pockets are able to secure supplies. 


Tips that may help the project manager to stave off potential problems around resource acquisition 
include: 


E For internally identified resources: Identify who the controlling stakeholder is so they can 
be brought into the primary stakeholder circle of the project. Identify what strategies must 
be actioned to ensure their continued buy-in and commitment to the project in order to secure 
needed resources to the project. (A commitment in email gained from them is exactly that: a 
‘commitment’ only—it will not form an internal department-to-department contract). 


E For externally sourced resources: The project manager needs to professionally engage with 
the supplier and again, develop the required stakeholder engagement strategy. It may be that 
the project manager has to enter into pre-contract conditions or retainers in order to secure the 
resource to the project. This technique is prevalent where internal resources are not available and 
externally, the resource is in scarce supply. 


Achecklist to support the acquisition of human and other resources could include items such as: 


E Isthe resource available at the timeslot required by the project? 


Em Ifthe timeslot changes, how does this affect the resource availability? 
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E Does the cost of the resource include any hidden costs (e.g. does the project pay superannuation 
payments in addition to the cross-charge for the resource?)? 


mg Are the resource costs within the expectations of the project? 


E Does the resource (if human) have the correct skills and competencies to be employed in the 
required role? 


Is the project willing to address skills and competency gaps and fund training? 
Does the resource (if human) have the relevant industry experience? 


Where is the resource being sourced from? 


Will there be difficulties in communicating with the resource (if human) in terms of language, 
cultures or, more commonly, time differences? (PMI, 2017) 


When considering the acquisition of resources, a project manager must contemplate: 


1. Any ‘pre-work’ required during the Planning stage of the project: Ensure that resources will be 
available when they are required, and in the correct amounts they are needed (i.e. there are no 
unwanted surprises). 

2. Resource-readiness (in the Executing stage of the project): Ensure that required resources are 
scheduled to the project at the right-time (i.e. in/on time). It is no good for example, having 
expensive hea viHift equipment on site at the right time if its operator has not been inducted 
into site workplace health and safety practices, has not completed necessary administrative 
paperwork, and so on. This alone could result in a 0.5-day schedule slippage. Resources need 
to be aligned with the activity they are required for—this includes licensing, certifications, 
quantities and quality of resources needed, for example. 


13.6 MONITORING AND CONTROLLING RESOURCES 


The project schedule will drive when resources are planned to be on-boarded to the project. The 
project manager must consider resource scheduling carefully (whether human or other resources), 
as during the monitoring and controlling stage of these resources, the project manager will be 
using the project’s schedule as a baseline from which to monitor any variances in resource usage. 
The project manager needs to carefully consider what they are monitoring in terms of resources. 
For instance: 


m Was the resource made available at the scheduled time it was planned for in the project schedule? 


E Does the project schedule represent (and has it been updated with) all change requests? Also, 
has the subsequent impact of the change request on resources to be used in the future also 
been checked? 


E Ifa project is using pooled resources (organised by a project management office (PMO)), the 
project manager will need to check whether other projects pulling on the same pooled resources 
have changed their needs for the resource. It may be that the resource will now not be available 
when it is needed, due to slippage of time in a dependent project. 


E For human resources: Have personnel arrived with the requisite (mandatory) skills? Were they 
inducted into the project in time to start work on allocated work packages, at the scheduled 
start time? 


Also for human resources: Has anything changed in the political landscape / in the marketplace 
that may affect resourcing of the project? For example, has a new mine site been announced that 
pays above market rates—if so, what is / what could be the impact to resources on our project? 
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If (physical) resources (such as tools and equipment) are committed to the project over a longer 
duration, what standby arrangements have been put in place in order to mitigate the risk of the 
resource not being available? 


Do (physical) resources (such as tools and equipment) committed to the project over a longer 
duration have an appropriate maintenance schedule and has this been accounted for in the 
project’s schedule and budget? 


Is the expected output rate being obtained from the resource? Were expectations of what the 
resource could produce overly optimistic? This could apply to human resources (e.g. number of 
‘story points’ attended to by a developer) and to physical resources (e.g. number of tonnes of dirt 
shifted per hour by a backhoe). Procedures must be established in the project at the relevant. 
WBS level to track such metrics, and allow for identification of where variances are occurring so 
corrective actions can be taken (usually via the project's change request process). 


What happens when an internal resource that has been committed to the project is suddenly not 
available at the point the project requires it? Hopefully, the project manager has read this book 
and has carried out a risk review of all WBS resource allocations during the Planning stage of the 
project. In this case, they will have a Risk Contingency Plan to fall back on that’s ready to go for 
these types of identified highlevel resource risks. 


Have ‘quality of work’ and ‘schedule of payments’ been appropriately linked so the project 
manager knows when a resource has produced the correct quality of work, which then triggers 
payment for the work achieved? Miscommunication about the work achieved in a project and 
lack of payment for that work from the project finance department has been known to lead to the 
withdrawal of resources from a project until payment has been received for work done! 


Being allocated lesser quality resources in lieu of planned resources—for example, an 
experienced developer is initially promised to the project, but a graduate with no experience is 
sent instead; or a planned concrete pump, capable of 140 cubic metres/hour was promised, but a 
65 cubic metres/hour pump turns up on site. 


The project manager must therefore ensure there are the correct checks and balances in place to 


ensure that resources turn up at the scheduled time, produce the promised outputs and are remunerated 
accordingly. 


13.6.1 Resource release/disposal 


Resources which are not consumed during the project will have to be released or disposed of at the 
end of the project. 


For human resources, this could mean releasing contractors, returning internally sourced 
employees back to business as usual operations, or promoting project team members to project 
roles on other projects. 


For physical resources, this could be the return of equipment to a hire/lease company, the 
environmentally considerate disposal of unused raw materials, or sale of equipment no longer 
required. 


When resources of any type are on-boarded into the project (at the resource acquisition stage), it 


is important to also consider at or before this stage how that resource will exit the project at project 


closure (if it is not consumed during the project). The project manager should ensure that suitable 


arrangements have been considered, any risks identified, associated costs estimated and work 


package activities included in the project schedule. 
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13.7 SCRUM (AGILE) CONSIDERATIONS 


Many considerations, from a pure resource planning, acquisition and monitoring perspective in a 
Scrum (Agile) approach, relate to: 


1. Identifying other resources required in the sprint, such as tools, equipment and facilities 
arrangements. In a typical IT project, this could mean: 


— identifying suitable office space that enables the Scrum team to be co-located 


— purchasing the correct integrated development environment (IDE) in order to manage the frequent 
releases of software 


— ordering a subscription to Trello (an online solution to the popular Kanban wall). 


bo 


Identifying the ideal mix of skills required in the development team for any sprint that has been 
through sprint planning and whose content is therefore known, so the skills required to deliver 
the sprint can also be identified and sourced. 


The Scrum master, product owner and development team combined are effectively doing the same 
thinking as a traditional project manager, but for a much smaller chunk of work—a sprint. 

When scaled to a LeSS (Large-Scale Scrum) project, the Scrum master (in conjunction with the 
contributing product owners) may be able to plan resources for the epic, increment and sprint. (Refer 
to Chapter 3.) 


This chapter has focused on a number of topics about the identification, capture and planning of resources that are 
required to complete a project. When read in conjunction with Chapter 9 and Chapter 8, this chapter provides a 
complete view of how to estimate and then successfully schedule resources within the project's schedule. Topics 
discussed in this chapter include: 


The identification of all resource types required by a project, including human resources, tools, plant, equipment, raw 
materials, capital and services. 

The use of the resource breakdown structure (RBS), the work breakdown structure (WBS) and Resource Allocation 
Matrix (RAM) to ensure a comprehensive approach is taken towards the identification of resources and the allocation 
of these resources to the project's work packages. 

Considerations to be aware of when allocating resources and on-boarding these to the project at the required time 
in the project. 

The monitoring and controlling of resources, which is particularly critical during the Executing stage of the project, 
and how to avoid some common issues that may arise. 

How these concepts can be applied in a Scrum (Agile) approach towards the planning of resource commitments, in 
planning epics, increments and sprints. 


https://www.pmi.org/learning/library/project-management-offices-mastering-resource-67 71 
https://www.praxisframework.org/en/knowledge/resource-management 
https://www.apm.org.uk/body-of-knowledge/delivery/resource-management/ 
https://www.youtube.com/watch?v=Ys4Rk3 Y8kmc 


https://support.office.com/en-us/article/pro ject-management-goal-manage-resources-fbf584d4-0590-4624-9fdf- 
3b7515c4df48 
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brainstorming Resource Allocation Matrix (RAM) Resource Matrix 

change management resource breakdown structure (RBS) team building 

lessons-learned resource categories training needs analysis (TNA) 
monitoring and controlling resources resource cycle work breakdown structure (WBS) 
RASCI Matrix Resource Management Plan 


Review questions 





41. What does a Resource Management Plan highlight the need for, when undertaking resource management? 
2. Provide eight examples of resource categories. 
3. Why is a RASCI useful when organising human resources? 
4. Why is a RAM useful? 
5. What additional projected information can be useful to a project manager when they are planning human resource 
needs? 
6. Name three resource identification techniques. 
7. Identify a minimum of four factors that can affect the acquisition of resources. 
8. Why do we monitor and control resources? 
9. What is the resource cycle? Why is it important to the project manager? 
10. How does project resource management present itself in a Scrum (Agile) approach? 


4. Using your class's Case Study (or a live project you are currently working on if you prefer), utilise the RBS and/or WBS, to 
identify resource requirements. 

2. For the resources identified, build the WBS and define a RAM for the project, allocating who is responsible, accountable, 
supports, is consulted, and is informed about the work package level of the project. 

3. Discuss in your class group(s) some of the issues you have personally experienced when monitoring and controlling 


resources in a project you have worked on. 
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THE PROJECT MANAGER 
AND PROJECT TEAMS 





Learning elements 


Understand the role of the modern project manager, including the attributes of the 
PMI talent triangle and codes of ethics. 


Understand and tackle the challenges involved with sourcing project teams. 


Understand and tackle the challenges of building project teams (including training, 
coaching and mentoring team members). 


Understand and tackle the challenges of managing project teams (including 
managing performance and team conflict). 


Understand and tackle the challenges of disbanding project teams. 
Understand managing virtual project teams. 


Be able to define servant leadership, and understand how the approach is 
leveraged in Scrum environment and its applicability to the project manager. 


In this chapter 


14.1 Introduction 


14.2 Understanding the role of a 
modern project manager 


14.3 Managing versus leading a project 


14.4 Building and leveraging your 
networks 


14.5 Ethics and the project manager 


14.6 Building trust: The key to 
exercising influence 


14.7 The project manager as a leader 
14.8 Project teams 

14.9 Building project teams 

14.10 Managing project teams 

14.11 Disbanding project teams 
14.12 Servant leadership 


Summary 
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14.1 INTRODUCTION 


In this chapter we look at some of the various skills and abilities a project manager needs in order to 
successfully initiate, plan, execute, monitor and control, and close a project. Some of these skills and abilities 
come in the form of learning new, or enhancing existing, soft skills. Other skills could be more tangible, for 
example, tools or techniques that the project manager can apply, to learn and assess aspects of: 


E the project team 
E the project environment 


@ the culture of the organisation. 


This chapter has three key sections: The first section discusses the role and skills of the project 
manager; the second section covers project teams (from sourcing teams, building and managing teams, 
through to disbanding project teams); and the third section tackles the topic of servant leadership as 
the preferred management style of the Scrum master (first raised in Chapter 3). 


14.2 UNDERSTANDING THE ROLE OF A MODERN 
PROJECT MANAGER 


In today’s complex, fast-paced business environment, there is no room for ‘accidental’ project 
managers. Project managers need to be trained professionals who have prior knowledge and 
experience in project management. They should already have acquired formal qualifications in 
project management (e.g. the Certificate IV, Diploma or Advanced Diploma in Project Management), 
or industry certifications and membership (e.g. PMP, Scrum, Agile DSDM, IPMA). This will enhance 
their chances of successfully leading projects of all complexities and sizes. 

Figure 14.1 illustrates the key skill groups the authors see successful project managers having— 
the ‘hats’ a project manager should be able to comfortably wear: 


E Subject matter expert (SME): Although there is much debate on this point, most organisations 
(through their recruitment processes) ensure that, in addition to sound project management 
abilities and qualifications, the candidate will have relevant industry experience. One school of 
thought is that if the project manager has an already-proven track record in project management 
then, in theory, by leveraging the small and mediumsized enterprises they manage as part of 
the project team, they should be able to manage a project of almost any content. Another school 
of thought is to employ only project managers who have a background in the industry/sector/ 
subject area. If you find yourself currently in the job-seekers’ market looking your next project 
management position or contract, you will probably actually find that the latter school of thought 
is the more prevalent. As a profession however, the former applies, as project management is 
taught as a generic skill, which is portable across most sectors and industries. 


E Organisational change management skills: Organisational change management is a specialist 
skill (not to be confused with routine project change control management, which is carried 
out as part of monitoring and controlling a project). Most projects involve changing the status 
quo; the project sets out to move a current (‘asis’) state to a new (‘tobe’) state. Managing 
the organisation and the people within the organisation through this change is the role of an 
organisational change manager. On large, complex projects, the organisational change manager 
role may be specifically recruited to an organisation. At other times, the company may employ 
an organisational change specialist who can be seconded to the project for short durations to 
provide expertise. From a project manager's perspective, this means that opportunities are often 
available to ‘up-skill’ and build knowledge in this area; after all, as a project manager you will be 
dealing with change on a daily basis. 
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E Leadership and team management skills: These skills are often acquired through general 
leadership and work experience. They may include communication, negotiation, performance 
management, team/people management, timemanagement, customer service, presentation 
and decisionmaking skills. While nearly all of these skills can be taught from a theoretical 
perspective, they can be greatly enhanced by real life experience, and through coaching and 
mentoring received in the workplace. 


E Project management skills: These are the set of skills, tools, and techniques that enable the 
project manager to successfully carry out the management of a project. Scoping the work, 
estimating, scheduling, managing budgets, managing project change and risk management are 
but a few of the project management tasks a project manager will be involved with. As a project 
manager, we seek qualifications such as the Australian Certificate IV and Diploma in Project 
Management Practice to demonstrate such skills. 


As can be seen from Figure 14.1, the project manager will be ‘a jack of all trades and a master of 
one’ (project management, of course!) Project management is, at first glance, a ‘misleading’ discipline 
in that while there is an inherent logic in the progression from formulating a project scope statement, 
creating a work breakdown structure (WBS), developing a project schedule, adding resources, 
agreeing baselines and reaching milestones. However, when it comes to actually implementing and 
completing projects, this logic quickly disappears, and project managers encounter a much messier 
world, filled with inconsistencies and paradoxes. Effective project managers have to be able to deal 
with the contradictory nature of the work; some of these contradictions are considered below: 


E Innovate and maintain stability: Project managers have to put out fires, restore order and 
get the project back on track. At the same time, they need to be innovative and develop new, 
better ways of doing things. Innovations can unravel stable routines, however, and spark new 
disturbances that have to be dealt with. 


E See the big picture while getting your hands dirty: Project managers have to see the big picture 
and how their project fits within the larger strategy of their firm. They must also often ‘get their 
hands dirty’ by getting deeply involved in project work and technology. After all, if they don’t 
worry about the details, who will? 


E Encourage individuals, but emphasise ‘team’: Project managers have to motivate and cajole 


and entice individual performers while at the same time maintaining teamwork. They have to 
be careful to be fair and consistent in their treatment of team members, while at the same time 
treating each member as a unique individual. 
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E Hands-off/frands-on: Project managers have to intervene, resolve stalemates, solve technical 
problems, and insist on different approaches. At the same time, they have to recognise when it is 
appropriate to sit on the sidelines and let other people figure out what to do. 


E Flexible but firm: Project managers have to be adaptable and responsive to events and outcomes 
that occur on the project. At the same time, they have to hold the line at times and tough it out 
when everyone else wants to give up. 


E Team versus organisational loyalties: Project managers need to forge a unified project team 
whose members stimulate one another to extraordinary performance. But at the same time, they 
have to counter the excesses of cohesion and the team’s resistance to outside ideas. They have to 
cultivate loyalties to both the team and the parent organisation. 


Managing these contradictions (and others) requires finesse and balance. Finesse involves being 
able to skilfully move back and forth between opposing behavioural patterns. For example, most 
of the time project managers actively involve others in discussions and decision-making, move by 
increment, and seek consensus. There are other times when project managers must act as autocrats 
and take decisive, unilateral action. Seeking a balance involves recognising the danger of extremes. 
Too much of a good thing invariably becomes harmful. For example, many managers have a tendency 
to always delegate the most stressful, difficult assignments to their best team members. This habit 
often breeds resentment among those chosen (‘why am I always the one who gets the tough work?) 
and never allows the ‘weaker’ members to develop their talents further. 

There is no one management style or formula for being an effective project manager. The world of 
project management is too complicated for formulas! Successful project managers have a knack for being 
able to adapt their approach styles to meet the demands of specific circumstances within a situation. 

So, what. qualities and abilities should one look for in an effective project manager? Many authors 
have addressed this question and have generated list after list of skills and attributes they associate 
with being an effective manager. When reviewing these lists, one sometimes gets the impression that 
to be a successful project manager requires someone with superhuman powers! While we agree that 
not everyone has ‘the right stuff’ to be an effective project manager, there are a number of core traits 
and skills that can (potentially) be learned by an individual to support their successful performance in 
the role of project manager. A number of these are outlined. 


1. Systems-thinker: Project managers must be able to take a ‘holistic’ rather than a ‘reductionist’ 
approach to projects. As well as breaking up a project into individual pieces (planning, budget) 
and managing it by understanding each part, a systems-perspective focuses on trying to 
understand how relevant project factors collectively interact to produce project outcomes. The 
key to success then becomes managing the interaction between different parts, and not the parts 
themselves. For example, if you are the project manager tasked with developing and embedding 
a new purchasing function within an organisation, you would not just simply take the purchasing 
process and break it. down into its constituent parts. Looking at the purchasing function 
from a systems perspective, you would look at where it fits within the organisation. It would, 
for instance, have interactions with the finance department, finance systems, warehousing, 
contracting, order fulfilment, customers and suppliers. 


2. Personal integrity: Before you can lead and manage others, you have to be able to lead and 
manage yourself! Begin by establishing a firm sense of who you are, what you stand for, and how 
you should behave. This inner strength provides the buoyancy to endure the ups and downs of the 
project life cycle and the credibility essential to sustaining the trust of others. 


3. Proactive: Good project managers take action before it is needed to prevent small concerns from 
escalating into major problems. They spend the majority of their time working within their sphere 
of influence to solve problems and not dwelling on things they have little control over. Project 
managers can’t be whiners! 


on 
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High emotional intelligence (EQ): Project management is not for the meek. Project managers 
have to have command of their emotions (and often emotions do run high in a project 
environment) so as to respond constructively to others when things get a bit out of control. See 
In Theory: Emotional Intelligence to read more about this quality. 


General business acumen: Because the primary role of a project manager is to integrate the 
contributions of different business and technical disciplines, it is important that they havea 
general grasp of business fundamentals and how the different functional disciplines interact to 
contribute to a successful business. A contract project manager who is new to an organisation 
may have to be careful not to inadvertently get on the wrong side of required people and/or 
departments that. are going to be involved in the project. Project managers often look to the 
project sponsor or executive for useful guidance about potential pitfalls to be avoided. 


Effective time management: Time is a manager's scarcest resource. Project managers have to 
be able to allocate their time wisely, and be able to quickly adjust their priorities. They need to 
balance their interactions so no one feels ignored. Time, in a project is, after all, finite. 

Skilful politician: Project managers have to be able to deal effectively with a wide range of 
people and win support and endorsement of their project. They need to be able to sell the virtues 
of their project without compromising the truth. It is often said that a good project manager will 
not be found sitting at their desk maintaining the project schedule, but will instead be found on 
the ground communicating with all those involved. 

Optimist: Project managers have to display a ‘can-do’ attitude. They have to be able to find rays 
of sunlight in a dismal day and keep people's attention positive. A good sense of humour and a 
playful attitude are often a project manager’s greatest strength. 

Story-teller: Project managers need to be able to construct a sound, compelling story of the 
future, that will encourage anyone, at any level, to join the project journey. However, the story 
should include the ‘point of pain’ (why we are doing this project), where we are moving from, 
how we are going to get to the endpoint, and what this endpoint will look like. Good leadership 
and optimistic story-telling skills can help to foster a re-energised, newly optimistic dimension to 
a project. 


In recent years, the Project Management Institute (PMI) has formally recognised the mix of skills 


that are needed by a project manager; the PMI refers to this mix as the ‘talent triangle’ (PMI 2017). 
It includes a mix of skills, including technical project management, leadership, and strategic and 
business management. A brief explanation of these three skills follows. 


14.2.1 Technical project management 


This category includes all the technical project management skills within the project environment. 
These will vary from project environment to project environment—for example, the Scrum master has 
a specific set of skills that are different to those of a project manager undertaking a more Predictive 
approach to managing a project. Each would be employed on the basis of their respective technical 
project management skills. Note that the PMI’s 1@ knowledge areas cover aspects of technical project 
management (as does this text). 


E Leadership On large projects, the project manager could have dozens to hundreds of people 


reporting to them directly and indirectly, so they must lead—be able to establish the ‘shared 
vision’ and bring everyone who is involved in the project (including stakeholders outside of 
the project) on board to take the journey towards success. To do this, they need to foster an 
optimistic, positive and collaborative approach. The ability to build trust, be able to negotiate 
and resolve conflict(s), act ethically and be considerate are some of the skills that fall into 
this category. They need to know their own leadership style, and understand concepts such as 
emotional intelligence (refer to In Theory: Emotional Intelligence). 
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E Strategic and business management In Chapter 4, we covered many aspects of this skillset, 

for example, understanding the process of ‘strategy formation’ (taking into consideration the 

internal and external environments); definition of the vision, mission, values and strategic goals; 

the selection of investments, leading to the development of the portfolio, programs and projects; 
through to the Business Case, which creates the focus for why the business needs to carry out the 
program/project. 

Along with the ability to make the strategic linkage, the modern project manager must have a 
good degree of business acumen, and be able to understand financial accounting and what business 
the organisational is in! They must be astute about finances, risk, values (benefits), costs (and 
funding) and the extended set of constraints (of scope, time, cost, quality, risk, resources) and the 
organisational strategy (refer to Chapter 4). Note: See also the discussion in Chapter 6, Figure 6.7 
Seven project constraints around the ‘seven constraints’ that are now more frequently considered. 


Some potential pathways towards understanding and (further) developing EQ are: 


= EQ workshop attendance, self-study and tailored courses that help to upgrade one’s general 
business perspective and capacity for systems-thinking. 


@ Training programs that can help individuals to improve their emotional intelligence, build their 
leadership skills, and grow their negotiation and conflict skills (plus numerous other skills 
potentially, depending on the training course). 


™ Coaching and mentoring that involve having practical work-based learning experiences. Trainees 
learn from their peers’ experience and expertise and may even be coached by senior staff (such 


as senior project managers and technical experts). 


IN THEORY Emotional Intelligence 





Emotional Intelligence (EQ) is the ability or skill of 
perceiving, assessing and managing your own emotions 
and/or those of others. Although the notion of EQ emerged 
in the 1920s, it was not until Daniel Goleman published 
his book Emotional intelligence {in 1995) that the concept 
captured the attention of business people and the 
public alike. Goleman divided EQ into the following five 
emotional competences: 


1. Selfawareness—knowing your emotions, recognising 
feelings as they occur and understanding the link 
between your emotions and your behaviour. Self- 
awareness is reflected in confidence, realistic 
assessment of personal strengths/weaknesses and 
ability to make fun of oneself. 


2. Selfregulation—being able to control disruptive 
impulses and moods and respond appropriately to 
situations. Selfregulation is reflected in trustworthiness 
and openness to change. 


3. Self:motivation—being able to gather up your 
feelings and pursue goals with energy, passion and 
persistence. The hallmarks of self-motivation include a 
strong desire to achieve, and internal optimism. 


4. Empathy—being able to recognise the feelings of 
others and tuning into their verbal and nonverbal 
cues. Empathy is reflected in the ability to sustain 
relationships and in cross-cultural sensitivity. 


5. Social skills—being able to build social networks and 
rapport with different kinds of people. Social skills 
include being able to lead change, resolve conflicts 
and build effective teams. 


It is clear to see how EQ can positively contribute towards 
being an effective project manager. In Goleman’s view, 
these competences build on each other hierarchically, At the 
bottom of the hierarchy is ‘self-awareness’. Some level of self- 
awareness is needed to move to ‘self-regulation’. Ultimately, 
social skills require all four of the other competences in 
order to begin to be proficient at leading others. Experts 
believe that most people can learn to significantly increase 
their EQ and numerous training programs and materials 
have emerged to help individuals ‘realise’ their EQ potential. 





Sources: Adapted from Bradberry T & Graves J 2005, The Emotional 
Intelligence @urck Baok: How to Put Your E@ to Work, Simon & Schuster. New 
York, Cabanis-Brewin J 1999, ‘The human task of a project leader: Danie! 
Goleman on the value of high EQ’, PM Network, November 1999, pp. 38-42. 
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However, no workshop, training program or mentoring experience can transform a pessimist into 
an optimist, or provide a sense of purpose when there isn’t one. Optimism, integrity and even being 
proactive are not easily developed traits; a person needs to have this natural drive and interest. 


14.3 MANAGING VERSUS LEADING A PROJECT 


Ina perfect world, the project manager would simply implement the Project Plan and the project would 
be completed. The project manager would work with others to formulate a schedule, organise a project 
team, keep track of progress, and announce what needs to be done next (and then everyone would 
charge along). Of course, no one lives in a perfect world, and rarely does everything go according 
to plan. Project participants get tetchy; they fail to complement each other; other departments are 
unable to fulfil their commitments; technical glitches arise; work takes longer than expected. The 
project manager’s job is to get the project back on track. As a good manager, they expedite certain 
activities; figure out ways to solve technical problems; serve as a peacemaker when tensions rise; and 
make appropriate tradeoffs among time, cost and scope of the project. 

However, project managers do more than put out fires and keep the project on track. They also 
innovate and adapt to everchanging circumstances. They often have to deviate from what was 
planned and introduce significant changes in the project scope and schedule to respond to unforeseen 
threats or opportunities. For example, customers’ needs may change, requiring significant design 
changes midway through the project. Competitors may release new products that dictate crashing 
project deadlines. Working relationships among project participants may break down, requiring a 
reformulation of the project team. Ultimately, what. was planned or expected in the beginning may be 
very different from what was accomplished by the end of the project. 

Project managers are responsible for integrating assigned resources to complete the project 
according to plan. At the same time, they need to initiate changes in plans and schedules as persistent 
problems make plans unworkable. In other words, managers want to keep the project going while 
making necessary adjustments along the way. According to Kotter (2007) these two different activities 
represent the distinction between ‘management’ and ‘leadership’. Management is about coping with 
complexity, while leadership is about coping with change. 

Good management brings about order and stability by formulating plans and objectives, designing 
structures and procedures, monitoring results against plans, and taking corrective action when 
necessary. Leadership involves recognising and articulating the need to significantly alter the 
direction and operation of the project, aligning people to this new direction, and motivating them to 
work together to overcome hurdles produced by the change and to realise new objectives. 

Strong leadership, while usually desirable, is not always necessary to be able to successfully 
complete a project. Well-defined projects that encounter no significant surprises require little leadership, 
as might be the case in constructing a conventional apartment building, where the project manager 
simply administers the project plan. Conversely, the higher the degree of uncertainty encountered 
on a project—whether in terms of changes in project scope, technological stalemates, breakdowns 
in coordination between people and so forth—the more leadership is required. For example, strong 
leadership would be needed for a software development project in which the parameters are always 
changing to meet developments in the industry. 

It takes a special person to perform both roles well. Some individuals are great. visionaries who 
are good at exciting people about change. Too often though, these same people lack the discipline or 
patience to deal with the day-to-day drudgeries of managing. Likewise, there are other individuals 
who are very well organised and methodical and yet they lack an ability to inspire others. 

Strong leaders can compensate for their managerial weaknesses by having trusted assistants 
who oversee and manage the details of the project. Conversely, a weak leader can complement their 
strengths by having assistants who are good at sensing the need to rally project participants. Still, one 
of the things that renders good project managers so valuable to an organisation is their ability to both 
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manage and lead a project. In doing so, they recognise the need to manage project interfaces and build 
a social network that allows them to find out what needs to be done, and can obtain the cooperation 
that is necessary to achieve this. 


14.4 BUILDING AND LEVERAGING YOUR NETWORKS 
14.4.1 Mapping dependencies 


The first step towards building a network is to identify those on whom the project depends for its 
success. The project manager (and their key assistants) therefore need to ask the following questions: 


m Whose cooperation will we need? 
m Whose agreement or approval will we need? 


m Whose opposition would keep us from accomplishing the project? 


Many project managers find it helpful to draw a map of these dependencies. For example, 
Figure 14.2 contains dependencies identified by a project manager responsible for installing a new 
financial software system in her company. 

It is always better to overestimate rather than underestimate dependencies. All too often, talented 
and successful project managers are derailed because they are blindsided by someone whose position 
or power they had not anticipated. After identifying who the project will depend on, the project manager 
can, effectively, step into their shoes to see the project from that person's perspective. For example: 


m What differences exist between me and the people on whom I depend (goals, values, pressures, 


working styles, risks)? 










Information 
technology 
manager 
Software 
vendor 










Software 
installation 


project 











Information 
technology 
director 







Billing and 
receipts 





CHAPTER 14 THE PROJECT MANAGER AND PROJECT TEAMS 


m How do these different people view the project (supporters, indifferents, antagonists)? 
Æ What is the current status of the relationship I have with the people I depend on? 


E What sources of influence do Ihave relative to those on whom I depend? 


Once the project manager starts this analysis, they can begin to appreciate what others value 
and what currencies (if any) they might be able to offer as a basis on which to build a working 
relationship. The project manager will also begin to realise where potential problems may lie— 
professional working relationships in which they have a current ‘debit’ or no convertible ‘currency’ 
to trade. Diagnosing the project from another person’s point of view can help the project manager 
to anticipate the other person’s reactions and feelings about project decisions and actions. This 
information is vital for selecting the appropriate influence strategy and tactics and for conducting 
successful negotiations. 

In our example, after mapping her dependency network, the project manager in charge of 
installing the software system realised she was likely to have serious problems with the manager of 
the receipts department (who would be one of the primary users of the software). She had no previous 
history of working with this individual but had heard through the grapevine that the manager was 
upset with the choice of software. She had also heard that he considered this project to be another 
unnecessary disruption of his department’s operation. Prior to project initiation, therefore, the project 
manager arranged to have lunch with the manager and she sat patiently and listened to his concerns. 
She invested additional time and attention to educate him and his staff about the benefits of the new 
software. She tried to minimise disruptions the transition would cause in his department and she 
altered the implementation schedule to accommodate his preferences as to when the actual software 
would be installed and when the subsequent training would occur. As a result, the receipts manager 
and his personnel were much more accepting of the change, and the transition to the new software 
went more smoothly than had been initially anticipated. 


14.4.2 Management by wandering around (MBWA) 


The preceding example illustrates the next step in building a supportive social network. Once the 
project manager has established whe the key players are who will determine success, they next need 
to initiate contact and begin building a relationship with those players. A management style that can 
help foster positive professional working relationships is what employees at Hewlett-Packard refer 
to as management by wandering around (MBWA). MBWA reflects the fact that good managers 
tend to spend the majority of their time outside of their offices, among the people who are doing the 
work. MBWA is somewhat of a misnomer however, as there is actually a purpose/pattern behind the 
‘wandering’. Through face-to-face interactions, project managers can stay in touch with what is really 
going on in the project and can seek to enhance cooperation that is essential to the project’s success. 

Effective project managers initiate contact with key players to keep abreast of developments, 
anticipate potential problems, provide encouragement, and reinforce the objectives and vision of the 
project. They are able to intervene to resolve conflicts and prevent stalemates from occurring. By 
staying in touch with various aspects of the project, they become the focal point for information on 
the project. Participants turn to them to obtain the most current and comprehensive information about 
the project, which reinforces their central role as the project manager. 

We have observed less effective project managers who have deliberately avoided taking a MBWA 
approach. They typically attempt to manage projects from their offices and computers. They proudly 
announce their ‘open-door policy’ and encourage others to come to see them when a problem or an 
issue arises, but to them, no news is good news! This allows their contacts to be determined by the 
relative aggressiveness of others. People who take the initiative to seek out the project manager get 
too high a proportion of the project manager's attention compared to people who are off-site and 
therefore cannot easily pop in to speak with them and people who are more passive and therefore may 
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be reluctant to ‘bother’ the project manager by approaching them directly. This behaviour contributes 
to the adage ‘only the squeaky wheel gets greased’ and yet this type of arrangement can breed real 
resentment within the project team. 

Effective project managers find the time to regularly interact with more distant stakeholders. 
They keep in touch with suppliers, vendors, top management. and other functional managers. In doing 
so, they maintain familiarity with the different parties, sustain friendships, discover opportunities to 
work more effectively, and better understand the motives and needs of others. They remind people of 
commitments and champion the cause of their project. They also shape people’s expectations. Through 
frequent communication, they alleviate people’s concerns about the project, dispel rumours, warn 
people of potential problems, and lay the groundwork for dealing with setbacks in a more effective 
manner. 

Unless project managers take the initiative to build a network of supportive relationships, they are 
likely to see a manager (or other stakeholder) only when there is bad news or when they needa favour 
(e.g. they don’t have the data they promised or the project has slipped behind schedule). Without 
prior, frequent, easy give-andtake interactions about nondecisive issues, an encounter prompted by 
a problem is likely to provoke excess tension. The parties are more likely to act defensively, interrupt 
each other, and lose sight of the common problem. 

Experienced project managers recognise the importance of building relationships before they 
need them. They initiate contact with key stakeholders at times when there are no outstanding issues 
or problems, and therefore no anxieties and suspicions. On these social occasions, they engage in 
smallHalk and responsive banter. They respond to others’ requests for aid, provide supportive counsel 
and exchange information. In doing so, they establish credit in that relationship—which will allow 
them to deal with more serious problems down the road. When one person views another as being 
pleasant, credible and helpful (based on previous contact) they are much more likely to be responsive 
to requests for help and be less confrontational when problems arise. 


14.4.3 Managing upward relations 


Research consistently points out that project success is strongly affected by the degree to which 
a project has the support of top management. Such support is reflected in an appropriate budget, 
responsiveness to unexpected needs, and a clear signal to others in the organisation of the importance 
of cooperation. 

Visible top management. support is not only critical for securing the support of other managers 
within an organisation, it is also a key factor in the project manager's ability to motivate the project 
team. Nothing establishes a manager's right to lead more than their ability to defend. To win the loyalty 
of team members, project managers have to be effective advocates for their projects. They have 
to be able to get top management to rescind unreasonable demands, provide additional resources, 
and recognise the accomplishments of team members. This is more easily said than done, of course. 
Working relationships with upper management is often a common source of consternation. Project 
managers are typically heard saying things along the lines of: 


m ‘They don’t know how much it sets us back, losing [name] to another project!” 
m ‘I would like to see them get this project done with the budget they gave us!’ 


m ‘Ijust wish they would make up their minds as to what is really important!’ 


While it may seem counterintuitive for a ‘subordinate’ to manage a ‘superior’, smart project 
managers devote considerable time and attention to influencing and garnering the support of top 
management. Project managers have to accept profound differences in perspective and become 
skilled at the art of persuading superiors. Many of the tensions that arise between upper management 
and project managers are as a result of differences in perspective. Project managers become 
naturally absorbed with what is best for their project. To them, the most important thing in the 
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world (well, at least in their working day) is their project! Top management should 
have a different set of priorities. They will be concerned with what is best for the 
entire organisation. It is only natural for these two interests to conflict at times. For 


Figure 14.3 T 
of a project sp 


example, a project manager may lobby intensively for additional personnel (sourced 
from other departments), only to be turned down because top management believes 
the other departments cannot afford a reduction in their staff. Although frequent 
communication can minimise differences, the project manager has to accept the fact 
that top management is inevitably going to see the world differently. 

Once project managers accept that disagreements with superiors are more a 
question of perspective than substance, they can focus more of their energy on the 
art of persuading upper management. But before they can persuade superiors, they 
must first prove loyalty. Loyalty in this context, simply means that most of the time 
project managers have to show that they consistently follow through on requests 





and adhere to the parameters established by top management (without a great deal 

of grumbling or fuss). Once they have proven their loyalty to upper management, 

senior management is likely to be much more receptive to challenges and requests. Project managers 
have to cultivate strong ties with upper managers who are sponsoring the project. As noted earlier, 
these are usually highranking executives who have championed the approval and funding for the 
project and as such, their reputations will be aligned with the project. 

Sponsors will defend the project when it is under attack in upper circles of management. They 
shelter the project from excessive interference (see Figure 14.3). Project managers should always 
keep such people informed of any problems that may cause embarrassment or disappointment. For 
example, if costs are beginning to outrun the budget, or a technical glitch is threatening to delay 
the completion of the project, then the project manager must make sure the sponsors are the first 
to know. 

Timing is everything: for example, a request for additional funding made the day after disappointing 
thirdquarter earnings are reported is less likely to be accommodated than if the request were 
submitted four weeks earlier. Good project managers pick the optimum time to make an appeal to top 
management. They enlist their project sponsors to lobby their cause. They also realise there are limits 
to top management's accommodations. Here, the Lone Ranger analogy is appropriate—‘you have only 
so many silver bullets, so use them wisely’. 

Project managers need to adapt their communication pattern to that of the senior group. For 
example, one project manager recognised that top management had a tendency to use sports 
metaphors to describe business situations, so she framed a recent slip in schedule by admitting that 
‘we took two steps backwards, but one step one forward’. Smart project managers learn the language 
of top management and use it to their advantage. 

Finally, a few project managers admit ignoring chains of command. If they are confident that top 
management will reject an important request and that what they want to do will benefit the project, 
they do it without asking permission. While acknowledging that this is very risky, they claim that 
bosses typically won't argue with success. 


14.4.4 Leading by example 


A highly visible, interactive management style is not only essential for building and sustaining 
cooperative relationships, it also allows project managers to utilise their most powerful leadership 
too]—their own behaviour. Often, when faced with uncertainty, people look to others for cues as 
to how to respond and they demonstrate a propensity to mimic the behaviour of their ‘superiors’. A 
project manager’s behaviour symbolises how other people should work on the project. Through their 
behaviour, they can influence how others act and respond to a variety of issues related to the project. 
To be effective, project managers must ‘walk the talk’ (see Figure 14.4). 
Next, we take a look at six aspects of how to lead by example. 
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Figure 14.4 Leading by € 
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PRIORITIES 


Actions speak louder than words. 





Subordinates and others discern project 
managers’ priorities by how they spend 
Problem their time. If a project manager claims 
solving that a particular project is critical but is 
then perceived as devoting more time 
to other projects, then all of their verbal 
reassurances are likely to fall on deaf ears. 
Conversely, a project manager who takes 
Priorities the time to observe a critical test, instead of 
simply waiting for a report about the test, 
affirms the importance of the testers and 
their work. Likewise, the types of questions 
project managers pose can communicate 
priorities. For example, by repeatedly 
Cooperation asking how specific issues relate to 
satisfying the customer, a project manager 
can reinforce the importance of customer 
satisfaction. 


URGENCY 


Through their actions, project managers can convey a sense of urgency that can permeate project 


activities. This urgency, in part, can be conveyed through stringent deadlines, frequent status report 
meetings, and aggressive solutions for expediting the project. The project manager uses these tools 
like a metronome to pick up the beat of the project. At the same time, such devices will be ineffective 
if there is not also a corresponding change in the project manager's behaviour. If they want others 
to work faster and solve problems quicker, then they need to work faster themselves: they need to 
hasten the pace of their own behaviour. They should accelerate the frequency of their interactions, 
talk and walk more quickly, get to work sooner, and leave work later. By simply increasing the 
pace of their daily interaction patterns, project managers can reinforce a sense of urgency 
in others. 


PROBLEM-SOLVING 


How project managers respond to problems sets the tone for how others tackle problems. If bad news 
is greeted by verbal attacks, then others will be reluctant about being forthcoming. If the project 
manager is more concerned with finding out who is to blame instead of how to prevent problems 
from happening again, then others will tend to cover their tracks and cast the blame elsewhere. If, on 
the other hand, project managers focus more on how they can turn a problem into an opportunity, or 
how to learn from a mistake, then others are more likely to adopt amore proactive approach towards 
problem-solving. As a project manager we should be seeking to locate the facts behind the root cause 
of the problem and not jump to attributing blame, or playing the ‘blame game’. 


COOPERATION 


How project managers act towards ‘outsiders’ influences how team members interact with outsiders. 
If a project manager makes disparaging remarks about the ‘idiots’ in the marketing department, for 
example, then this (often) becomes the shared view of the entire team. If project managers set the 
norm of treating outsiders with respect and being responsive to their needs, then others will more 
likely follow suit. 
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STANDARDS OF PERFORMANCE 


Veteran project managers recognise that if they want participants to exceed project expectations, 
they must themselves exceed others’ expectations in their role of project manager. They establish a 
high standard for project performance through the quality of their daily interactions. They respond 
quickly to the needs of others, carefully prepare and run ‘crisp’ meetings, stay on top of all the critical 
issues, facilitate effective problemsolving and stand firm on important matters. 


ETHICS 


How others respond to ethical dilemmas that arise in the course of a project will be influenced by 
how the project manager has responded to similar dilemmas. In many cases, team members base 
their actions on how they think the project manager would respond. If project managers deliberately 
distort or withhold vital information from customers or top management, then they are signalling to 
others that this kind of behaviour is acceptable. Project management invariably creates a variety of 
ethical dilemmas—we will now take a look at this topic in more detail. 


14.5 ETHICS AND THE PROJECT MANAGER 


Questions of ethics have already arisen in previous chapters, which discussed, for example, 
potential padding of cost and time estimations and the exaggeration of project pay-offs in project 
proposals. Ethical dilemmas involve situations where it is difficult to determine whether conduct 
is right or wrong. For example, is it acceptable to falsely assure customers that everything is on 
track when, in reality, you are only telling them this to prevent them from panicking and making 
matters worse? 

Project managers often report that they have encountered ethical issues in their work. Examples 
include being pressured to alter status reports, the backdating of signatures, the shading of 
documentation to mask the reality of project progress, falsification of cost accounts, safety standards 
being compromised to accelerate progress, and approving shoddy work. 

Project management is complicated work and, as such, ethics invariably involve grey areas 
of judgement and interpretation. For example, it may be difficult to distinguish the deliberate 
falsification of estimates from genuine mistakes, or the wilful exaggeration of project payoffs from 
genuine optimism. It becomes problematic when trying to determine whether unfulfilled promises 
were deliberate deceptions or, alternatively, an appropriate response to changing circumstances. To 
provide greater clarity about business ethics, many companies and professional groups publish a code 
of conduct. Cynics see these documents as simply ‘window-dressing’, while advocates argue that they 
are important (albeit limited) first steps. In practice, personal ethics do not lie in formal] statutes but 
at the intersection of one’s work, family, education, profession, religious beliefs and daily interactions. 
Most project managers report that they rely on their own private sense of right and wrong—what 
one project manager called his ‘internal compass’. A common rule of thumb for testing whether a 
response/a choice is ethical involves imagining that whatever you choose to do is going to be reported 
on the front page of your local newspaper and, potentially, in social media (e.g. see Snapshot from 
Practice: The ethical project manager). Would you be comfortable with your choice/decision? Could 
you ‘live with it? What would the impact to the business be? Would the choice/decision endanger lives 
of customers or the community? 

Unfortunately, scandals at Enron, Worldcom, Arthur Andersen and, more recently, Carillion 
PLC (which went into compulsory liquidation in 2018), have demonstrated a propensity for some 
highly trained professionals to abdicate personal responsibility around their actions and to obey 
the arguably somewhat unethical directives of superiors. Top management and the culture of an 
organisation can play decisive roles in shaping members’ beliefs of what is right and wrong. Some 
organisations indirectly encourage ethical transgressions by fostering a ‘win at all costs’ mentality. 
Pressures to succeed can obscure consideration of whether the ends justify the means. Conversely, 
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SNAPSHOT FROM PRACTICE The ethical project manager 





Being a member of a professional organisation brings with 
it a commitment. In Australia, whether you are a senior 
executive and a member of the Australian Institute of 
Company Directors (AICD), a medical doctor and a fellow 
of a professional college, an electrician and a member of 
Master Electricians Australia, or a project manager and a 
member of the Australian Institute of Project Managers 
(AIPM), your membership of such organisations will entail 
signing up to a code of ethics. 

A number of elements are discussed, including 
‘professional conduct’ in the AIPM code of ethics: 


m Act with Integrity 


— Be honest and trustworthy 
— Demonstrate respect for others 
— Act with a clear conscience 


m Practice Competently 


— Maintain and develop knowledge and skills 
— Act on the basis of adequate competency 


m Demonstrate Leadership 
— Uphold the reputation of the profession 
m Act with Responsibility 


— Engage responsibly with the community 


— Foster health, safety and wellbeing 
— Balance the needs of the present with the needs 
of the future (AIPM 2014). 


To position your ethical behaviour, ask yourself what 
you would do in the following situation. 

You have a close friend working in your project. They 
are found to be ‘taking a backhander’ (a bribe) from a 
supplier to the project. Only you (as the project manager) 
know about this and you have only just discovered it is 
happening. Reporting the behaviour would mean losing 
a much-needed project resource at a critical point in the 
project’s execution. 

What would you do in this situation? 


(a) Keep quiet. 

(b) Contact your organisational human resources 
department and professional body. 

(c) Confront your friend yourself. 

(d) Call the police immediately and present your facts. 


The best way to approach such a situation would 
be (b), as you would not be ignoring the situation, and 
you would not need to confront your friend directly, but 
appropriate disciplinary action could be taken by the 
human resources department and/or the professional 
body so the unethical behaviour is (hopefully) 
discontinued. 


there are erganisatiens that place a premium en fair play and, as a result, cemmand an enhanced 
market pesitien by virtue ef being perceived as trustwerthy. 

Many preject managers claim that ethical behavieur is its ewn reward. By fellewing yeur ewn 
‘internal cempass’, yeur behavieur expresses yeur persenal values. @thers suggest that ethical 
behavieur is deubly rewarding: net enly will yeu be able te sleep seundly at night but yeu will 
alse develep a pesitive reputatien as a persen whe has seund integrity. As will be explered in the 
next sectien, such a reputatien is essential te establishing the trust necessary te exercise influence 
effectively. 


14.6 BUILDING TRUST: THE KEY TO 
EXERCISING INFLUENCE 


Trust can be defined as believing that ‘someone is good and honest and will not harm you, or that 
something is safe and reliable’ (Cambridge Dictionary n.d.). 

There are many dimensions of trust (either implied or stated) across the project environment. For 
example: 


E The project team trusts the project manager to create a safe working environment. 
E The project manager trusts the project sponsor to be open and honest with them in all their dealings. 


m The project management office trusts the project manager to provide an accurate and honest 
project status. 
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E Stakeholders trust the project has the business's interests ahead of any personal or organisational 
agendas. 


@ Project team members trust stakeholders are being honest about the requirements necessary 
from a new computer system. 


The significance of trust can be discerned by its absence. Imagine how different a working 
relationship is when you distrust the other party, as opposed to when you trust them. When people 
distrust each other, they often spend inordinate amounts of time and energy attempting to discern 
hidden agendas and the true meaning of communications, and then securing guarantees to promises. 
They are much more cautious with each other and can be hesitant about cooperating. Here is what one 
line manager had to say about how he reacted to a project manager he did not trust: 


Whenever Jim approached me about something, I found myself trying to read between the 
lines to figure what was really going on. When he made a request, my initial reaction was ‘no’ 
until he proved it. 


Conversely, trust is the lubricant that maintains smooth and efficient. interactions. When you 
are trustworthy, people are more likely to take your actions and intentions at face value when 
circumstances are ambiguous. For example, here is what a functional manager had to say about how 
he dealt with a project manager he trusted: 


If Sally said she needed something, no questions were asked. I knew it was important or she 
wouldn't have asked. 


Trust is an elusive concept. It is hard to nail down in precise terms why some project managers are 
trusted and others are not. One popular way to understand trust is to see it as a function of character 
and competence. ‘Character’ focuses on personal motives (i.e. does he or she want to do the right 
thing?), while ‘competence’ focuses on the skills necessary to realise motives (i.e. does he or she know 
the right things to do?). 

A list of tips for trust-building behaviours can be found in the web resource ‘Build trust and be 
transparent’ (Murray 2010). Some of the tips found in this web resource have been adapted and 
contextualised below: 


1. Be accountable for your actions: ‘Accountability involves claiming your own power and 
marshalling your internal resources to achieve better results. Accountability asks, “What can I 
do to make a difference?” Accountable behaviour enables you to take charge of your thoughts, 
feelings and actions.’ 


2. Act consistently with your words: ‘People will pick up immediately when you espouse one value 
with your words but demonstrate the opposite of that value through your actions.’ 


3. Live your values and communicate them regularly: ‘Review the primary values that allow 
you to inspire trust in others: honesty, responsibility, respect, fairness and compassion. First, 
ask yourself how often and how clearly you communicate and share these values with others. 
When facing a difficult situation, openly refer to these values and draw on them to make the 
best decision. Next, assess how well you live out these values in your daily routine and in your 
interactions with others.’ 


4. Admit mistakes and take blame: ‘We all make mistakes at work, and the negative consequences 


usually spill over and impact others. To maintain the respect and trust of co-workers, your boss, 
customers, vendors and suppliers, don’t hesitate to own your mistakes.” 


a 


Listen for understanding: ‘The very act of listening can build trust. By taking the time to 
listen and really seek to understand the opinion of others, you are demonstrating respect and 
acknowledging their unique perspective.’ 
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6. Act with integrity and ethics: ‘The most important action you can take to build trust in the 
workplace is to be honest and ethical. When speaking and communicating with others, tell the truth’ 


7. Bean advocate for a fear-free culture: ‘Warren Bennis of the University of Southern California 
discovered in his research that effective leaders build trust by being consistent and predictable in 
their behaviour, and attempting to truly listen and understand the perspective of others. 


8. Face reality: ‘In our conversations with others, we would all like to tell the truth as part of doing 
business, tackling new challenges or resolving hard issues. However, the task can be difficult, 
as we often fear that a difficult conversation will turn into an angry confrontation, stirring up 
emotions and causing a distraction’ 


9. Provide honest feedback: ‘One of the primary responsibilities of a leader is to provide feedback to 
others, especially the people who report directly to you. The act of providing feedback can help 
establish trust, but only if you have the courage to be honest.’ 


10. Build trust with openness: ‘The common, initial reaction to a mistake is to blame someone else. 
However, even apparently random errors occur due to the convergence of multiple contributing 
factors; sometimes the cause is people, sometimes the cause is the work process itself. You will 
never be able to discover true causes for problems unless you have a fear-free culture. Blaming 
individuals causes people to shut down their communication and limits their willingness to 
communicate the facts honestly.’ 


Stephen Covey resurrected the significance of ‘character’ in leadership literature in his best-selling 
publication Seven Habits of Highly Effective People (1989). Covey criticised popular management. 
literature as focusing too much on shallow human relations skills and manipulative techniques, which 
he labelled ‘the personality ethic’. He argued that at the core of highly effective people is a character 
ethic that is deeply rooted in personal] values and principles suchas dignity, service, fairness and the 
pursuit of truth and respect. 

One of the distinguishing traits of good character is consistency. When people are guided by a core 
set of principles, they are naturally more predictable because their actions are consistent with these 
principles. Another feature of good character is openness. When people have a clear sense of who they 
are, and what they value, they are more receptive to others. This trait provides them with the capacity 
to empathise and the talent to build consensus among divergent people. A further quality of good 
character is a sense of purpose. Managers who have good character are driven not only by personal 
ambitions but also motivations for the common good. Their primary concern is what is best for their 
organisation and for the project, not what is best for them personally. The willingness to subordinate 
personal interests to a ‘higher purpose’ generally garners the respect, loyalty and trust of others. 


14.7 THE PROJECT MANAGER AS A LEADER 


Knowing your personal leadership and management style is key to understanding reactions from 
those around you. Tannenbaum & Schmidt’s (1973) ‘leadership continuum’ (illustrated in Figure 14.5) 
outlines a simple model that is still often referenced in project management today. As can be seen, the 
manager's approach is placed on a continuum, from an autocratic style of management, through to a 
democratic style of management. 

The continuum indicates the relationship between the level of freedom that a manager chooses to give to 
a team and the level of authority applied by the manager. As the team’s freedom is increased, the manager's 
authority decreases. Most. managers have a preferred style. However, there are times when a manager 
may move between styles. For example, when a difficult. decision has to be made within the project that. 
has been the result of executive discussions, the project manager may move to a more ‘autocratic’ decision 
style. The different blends of authority and ‘freedoms of subordinates’ are outlined below: 


E The manager makes and announces the decision: In this style, the project manager reviews all 
appropriate options, in light of goals, issues, priorities, schedules and so on and decides which 
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Figure 14.5 Le ontinuum 
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announces decision ideas and tentative problem, limits; subordinates full 
decision invites decision gets asks to function freedom 
questions subjectto suggestions, groupfor within 
change makes decision superior 
decisions defined 
limits 


Source: Tannenbaum R & Schmidt WH 1973, ‘How to choose a leadership pattern’, Hervere Business Review, May—June, p. 12 


action to take and subsequently informs the project team of the decision. Although the project 
manager does need to consider how their team will react, and must be prepared for questions, the 
team plays no active part in actually making the decision. 


The manager ‘sells’ the decision to the greup: The project manager chooses which action to take (as 
in the previous approach style), but explains (‘sells’) the decision to the project team. In doing so, the 
project manager is more likely to be viewed as recognising the project team’s importance (and concern). 


The manager presents ideas and invites questions: The project manager presents their decision 
along with additional ideas (options) they have come up with. The project team is then invited 
to ask questions and to discuss the rationale for these ideas with the project manager. This style 
starts to gain buyin from the project team, as there is a higher level of team involvement and 
discussion (leading to a more empowered project team). 


The manager presents a tentative decision that is subject to change following discussion: The 
project manager discusses and reviews the provisional decision they have arrived at, with the 
project team, on the basis that the project manager will take on board the views of the project 
team before a decision is finalised. Here, the project team is more empowered to influence the 
project manager’s final decision. 


The manager presents the problem, canvasses suggestions and makes appropriate decisions: 
The project manager presents a situation to the project team. The project team is encouraged and 
expected to contribute ideas, suggest suitable options, and offer up enabling perspectives. The 
project team and the project manager then discuss all suitable options before a final decision is 
arrived at. The project team’s input is seen as being highly valued—its members contributing to 
the project and the decisions being made. 


The manager defines limits and asks the group for the decision: In this style, the project manager 
effectively delegates responsibility for making a decision to the project team (albeit within the 
project manager's stated limits). This style of approach really empowers the project team; however, 
the project manager still has to mitigate any risks that may result from the proposed decision. 
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E The manager permits ‘suberdinates’ te functien within ‘superier’ defined limits: Here, 
the project manager provides greater freedom for decision-making, but only within a set of 
parameters. For example, the project manager may increase the project team’s spending authority 
in order for the team to be able to make quicker, context-based decisions. 


E Manager allews full freedem: In mature projects where there is a high degree of trust between 
the project manager and the team, and where the team is considered highperforming, the project 
manager may give the project team full freedom. The team operates as the project manager 
would in the mode of ‘makes decisions and announces decision’. 


14.8 PROJECT TEAMS 


14.8.1 Sourcing project teams 

Sourcing project teams includes decisions around the selection of the project sponsor and project 
manager, through to sourcing all the other required members of the project team. Itis the project team 
that typically takes the most planning to acquire. This section on sourcing project teams will review 
some of the situations a project and project manager may be in at the outset of the project. 


14.8.2 Project sponsor 

At the stage where the project’s Business Case is issued (by the relevant management office), a 
sponsor for this Business Case would have been allocated (anda project manager may also have been 
identified). The portfolio/progranv project management office needs to carefully consider the choice 
of project sponsor—after all, it is well-known that having the right fit of project sponsor greatly 
increases the project's success. It is not uncommon for mature management offices to use a checklist 
approach towards checking sponsor and project alignment. The author (Pearson) observes some of 
the following traits of good sponsors: 


1. promote understanding of the root cause of the problem and do not dive in and address the 
symptoms 

2. understand the 80/20 rule and when ‘good enough’ is sufficient to provide a workable solution to 
the business 

3. corral the best team possible using the power of influence at management level to obtain the best 
resources for the most critical projects 

4. are the umbrella that shields the project, project manager and project team from unnecessary 
‘rainfall’ in terms of politics, company culture and other ‘noise’ factors 


on 


. offer the most positive, pro-active support to the project 


6. ensure the project manager and project team have clearly defined accountabilities and ensure 
they make good on these 


7. listen, take advice wisely and make sound decisions 


8. (in times of changing business environments) know when to prematurely terminate a project 
based on the presenting facts 


9. are clear, concise and factual in their communications 


10. are ethical in all their dealings. 


In selecting the project sponsor, the issuer of the Business Case must also consider: 


E The erganisatien's hierarchy: Is it flat or hierarchical? Does ‘position’ in the hierarchy affect 
the level of authority the sponsor may have, and if so, to what extent? For example, would the 
implementation of customer relationship management (CRM) software be best sponsored by the 
director of marketing, or the director of business development? 
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E The organisation’s culture: Are the necessary levels of empowerment and accountability being 
passed to the nominated sponsor in the organisation, to enable the project to be appropriately 
driven and directed? 


E The politics of the organisation: Would weak political players not have the ability to resolve 
escalated issues and gain the right backing from around the boardroom table? For example, 
if the business development department is seen as being aloof, would the project have greater 
success if it was sponsored by the director of marketing? 


The project sponsor can make or break a project and so their selection requires careful 
consideration. If the above considerations have not been taken into account when the project manager 
is appointed, then what leverage will the project manager have to question the choice of appointed 
project sponsor? Would they be able to gain a more suitable sponsor for the project if this needs to 
be challenged? Mature project organisations should be able to entertain such a challenge without 
repercussions. 


14.8.3 Project manager 


Once the project sponsor has been established, the next role to be recruited is that. of the project 
manager (and the project manager subsequently establishes the remainder of the project team). 
There are many potential considerations to take into account when sourcing a project manager. Some 
factors that come into play include: 


E The degree to which the organisation is projectised: For example, are there career project 
managers ‘benched’ in the program management office, ready to take on the next project, or is 
the organisation more ‘functional’ in design and a functional manager is to take on the role of 
managing the project? Refer to Chapter 5. 


E The organisation's human resource and recruitment policy: For example, some organisations do 
not have permanent project managers: their resourcing strategy is to go to the market to recruit 
project managers with previous experience in the required subject domain. 


E Secondment: If project manager skills exist in the organisation as part of the functional hierarchy 
but are not utilised full time, then a person who possesses the requisite skills will be seconded 
from their substantive role to manage the project on a full-time basis. Once the seconded person's 
project management responsibilities are complete, they return to take up their functional role 
within the organisation once more. 


Æ Contracting: Contacting in a project manager to work on a particular project is common. If 
carefully selected, contract project managers can bring with them technical project management 
skills and strong leadership, strategic and business-management skills (as noted in the PMI’s 
talent triangle). 


Regardless of whichever avenue a project manager is sourced from, it is essential that they possess 
the behavioural traits that were discussed earlier in this chapter to increase the likelihood of project 
success. A higher weighting may therefore be given at interview to the individual's leadership skills 
(and their cultural fit to the organisation), in combination with their business management skills. This 
is because it is far easier to subsequently train an individual to fill any technical gaps than it is to 
adjust ingrained behaviours and traits. 


14.8.4 Recruiting project members 


The actual process of selecting and recruiting project members will vary across organisations. Two 
important factors affecting recruitment will be the importance of the project, and the management 
structure being used to complete the project. For highpriority projects, considered as critical for 
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the future of the organisation, the project manager may be given almost carte blanche to select 
whomever they deem to be necessary (from across the business and outside). For less significant. 
projects, a project manager may need to persuade personnel from other areas within the organisation 
to join the team. 

In many matrix structures, the functional manager will control who is assigned to the project and 
the project manager will therefore have to work with the functional manager to obtain necessary 
personnel. Even in a project team where members are selected and assigned on a fulltime basis to the 
project, the project manager has to be sensitive to the needs of others. There is no better way to create 
enemies within an organisation than to be perceived as unnecessarily robbing other departments of 
essential personnel. Experienced project managers stress the importance of asking for volunteers. 
This desirable step often is outside the manager's control. Still, the value of having team members 
volunteer for the project as opposed to being assigned cannot be overlooked. Agreeing to work on the 
project is the first step towards building personal commitment to the project. Such commitment will be 
essential to maintain motivation when the project hits hard times and extra effort is required. 

When selecting and recruiting team members, project managers naturally look for individuals who 
have the necessary experience and knowledge or technical skills critical for being able to complete 
the project. At the same time, there are some less obvious considerations that also need to be factored 
into the recruitment process. These are: 


m Ability to problem-solve: If the project is complex and ‘fuzzy’, the manager will want people who 
are good at working under uncertainty and who have strong problemidentification and -solving 
skills. These same (often, highly creative) people are very likely to be bored and less productive 
when working on straightforward projects that are highly predictable. 


E Availability: Sometimes, the people who are most often available are not actually the ones 
wanted for the team. Conversely, it may be that a recruited person is already overcommitted 
when recruited, and if so, they are unlikely to be able to offer much value to the team. 


E Technological expertise: Managers should be wary of people who know too much about a specific 
technology. That may sound counterintuitive, but technology buffs who like to study and ‘tinker’ 
may sometimes have a hard time in being able to settle down and perform the work. 


Em Credibility: The credibility of the project is enhanced by the reputation of the people involved in 
the project. Recruiting a sufficient number of winners lends confidence to the project. 


@ Political connections: Astute managers frequently recruit individuals who already have a good 
working relationship with key stakeholders. This is particularly true for projects operating in 
a matrix environment in which a significant portion of the work will be under the domain of a 
specific functional department, and not the core project team. 


m Ambition, initiative and energy: These qualities can make up for a lot of shortcomings in other 
areas and should not be underestimated. 


E Attitude, ability and willingness to perform as part of a team: These traits are often harder to 
pick up in an interview situation by an inexperienced manager. Personality profiling can assist in 
identifying a person with a healthy attitude and who is a team player. 


14.9 BUILDING PROJECT TEAMS 


One of the challenges project managers often face in building a team is the lack of fulltime involvement 
of team members. Specialists work on different stages of the project and spend the majority of their 
time and energy elsewhere. They are often members of multiple teams, with each team competing 
for their time and allegiance. Project expert David Frame (1995) points out. that for many specialists, 
a specific project is an abstraction and as a consequence, their level of motivation suffers. Project 
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managers need to try to make the project team as real as possible to the participants, by developing a 
unique team identity to which participants can become emotionally attached. Team meetings, the co- 
location of team members, team names and team rituals are common vehicles for achieving a sense 
of team identity. These approaches are unpacked further below: 


E Effective use of meetings: Periodic project team meetings provide an important forum for 
communicating project information. A less obvious function of project meetings is to help 
establish a concrete team identity. During project meetings, members see that they are not 
working alone. They are part of a larger project team, and project success depends on the 
collective efforts of all the team members. Timely gatherings of all the project participants help 
define team membership and reinforce a collective identity. 


m Co-location of team members: The most obvious way to make the project team real is to have 
members work together in a common space. This is not always possible in matrix environments 
where involvement is part time and members are working on other projects and activities. A 
worthwhile substitute for colocation is the creation of a project office (sometimes referred to as 
the ‘project room’). Such rooms act as the common meeting place and contain the most significant 
project documentation. Frequently, their walls are covered with Gantt charts, cost graphs and 
other outputs associated with project planning and control. These rooms serve as a tangible sign 
of project effort. 


E Creation of project team name: By giving a team a name, the project team gains an identity and 
becomes much more tangible. Frequently, an associated team (or project) logo is also created. 
Again, the project manager should rely on the collective ingenuity of the team to come up with 
the appropriate name and logo. These symbols can then be printed on stationery, T-shirts, coffee 
mugs, etc. to help signify team membership. 


E Get the team to build or do something together as a team early on: Nothing reinforces a sense of a 
‘team’ more than working on something together. Holding a team BBQ, to which everyone brings a 
plate of food, can help to foster positive relations between team members in a relaxed manner. 


E Team rituals: Just as corporate rituals help establish the unique identity of a firm, symbolic 
actions at the project level can also contribute to a unique team subculture. For example, on 
one project, team members were given ties with stripes that corresponded to the number of 
milestones on the project. After reaching each milestone, members would gather and cut the next 
stripe off their ties to signify progress. Ralph Katz (2004) reports it was common practice for 
Digital Equipment’s alpha chip design team to recognise people who found a bug in the design 
by giving them a phosphorescent toy cockroach. The bigger the bug that was discovered, the 
bigger the toy cockroach received. Such rituals help to set project work apart from mainstream 
operations and reinforce a special status. 


14.9.1 Creating a shared vision 


Unlike project scope statements, which include specific costs, completion dates and performance 
requirements, the project vision involves less tangible aspects of project performance. It refers to an 
image the project team holds in common about how the project will look at completion, how they will 
work together, and/or how customers will accept the project. At its simplest level, a shared vision is the 
answer to the question, ‘What do we want to create?’ Visions come in a variety of shapes and forms; 
they can be captured in a slogan or ina symbol, or can be written as a formal project vision statement. 

What. a vision is, is not as important as what it does. A vision inspires members to give their best 
effort. Moreover, a shared vision unites professionals with different backgrounds and agendas to a 
common aspiration. It helps motivate members to subordinate their individual agendas and do what is 
best for the project. As has been wisely observed, ‘In the presence of greatness, pettiness disappears’. 
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Figure 14.6 Req 
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y and fast and that the car should be quick when pulling 
away, nimble in turns, and very fast on straight sections. 
Obviously, many details would have to be worked out, but 
the vision would help establish a common framework for 
making decisions. 
There appear to be four essential qualities of an effective vision (see Figure 14.6): First, its essential 
qualities must be able to be cemmunicated—a vision is worthless if it only resides in someone’s 
head! Second, visions have to be challenging, but. also realistic. For example, a task force directed at. 


Inspire others 


overhauling the curriculum for a university program in business at a university is likely to roll its eyes 
if the dean announces that their vision is to compete against the world-renowned Harvard Business 
School in the United States. Conversely, developing the best undergraduate business program in the 
state may be a realistic vision for that task force. Third, the project manager has to believe in the 
vision—passion for the vision is an essential element of an effective vision. Finally, the vision should 
be a seurce ef inspiratien to others. 

Once a project manager accepts the importance of building a shared vision, the next question is 
how to get a vision for a particular project. Project managers don't get ‘visions’! They act as catalysts 
and midwives for the formation of a shared vision. In many cases, visions are inherent in the scope 
and objectives of the project. People get naturally excited about being the first ones to bring a new 
technology to the market or solve a problem that is threatening their organisation. Even with mundane 
projects, there are often ample opportunities for establishing a compelling vision. One way is to talk to 
various people involved in the project and find out early on what gets them excited about the project. 
For some, it may be doing a better job than on the last project, or the satisfaction seen in the eyes of 
customers when the project is over. Many visions evolve reactively in response to competition. For 
example, we expect that Apple has the vision to make a watch that delivers beyond a ‘fitness tracking’ 
device to a device that ‘predicts and monitors health’ being able to detect strokes and heart attacks—this 
vision is prevalent in the media but is yet (as of 2018) to be made accurately functional in the device. 

Some experts advocate engaging in formal visionbuilding meetings. These meetings generally 
involve several steps, beginning with members identifying different aspects of the project and generating 
ideal scenarios for each aspect. For example, on a construction project the scenarios may include ‘no 
accidents’, ‘no lawsuits’, ‘winning a prize’ or ‘how we are going to spend our bonus for completing the 
project ahead of schedule’. The group reviews and chooses the scenarios that are most appealing and 
translates these into vision statements for the project. The next step is to identify strategies for achieving 
the vision statements. For example, if one of the vision statements is that there will be no lawsuits, 
members will identify how they will have to work with the owner and subcontractors to avoid litigation. 
Next, members volunteer to be the keeper of the flame for each statement. The vision, strategies and the 
name of the responsible team member are published and distributed to relevant stakeholders. 

In more cases than not, shared visions emerge informally. Project managers collect information 
about what excites participants about the project. They test bits of their working vision in their 
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conversations with team members, to gauge the level of excitement the early ideas elicit in others. To 
some extent they engage in basic market research. They seize opportunities to galvanise the team, 
such as by rejecting a disparaging remark by an executive that the project will never get done on 
time. Consensus in the beginning is not essential. What is essential is a core group of at least onethird 
of the project team that is genuinely committed to the vision. They will provide the critical mass to 
draw others on board. Once the language has been formulated for communicating the vision, then 
this statement needs to be a staple part of every working agenda and the project manager should be 
prepared to deliver a persuasive presentationtype speech at a moment’s notice. When problems or 
disagreements emerge, all responses should be consistent with the vision. 

Much has been written about visions and leadership. Critics argue that vision is a glorified 
substitute for shared goals. Others argue that it is one of the things that separates leaders from 
managers. The key is discovering what excites people about a project, being able to articulate this 
source of excitement in an appealing manner, and protecting and nurturing this source of excitement 
throughout the duration of the project. 


14.9.2 Tuckman and Jensen’s five-stage team development model 


Just as most infants develop in predictable ways during their first months of life, many experts 
argue that groups also tend develop in a predictable manner. One of the most popular models used to 
explain this process was developed by Bruce Tuckman (1965). Although developed a while ago now, 
this model is still often used to explain team formation and development. It comprises five stages 
(see Figure 14.7) through which groups develop into effective teams. (Note: The model originally 
contained only four stages, but the fifth—Adjeurning—was added in 1977 jointly by Bruce Tuckman 
and Mary Ann Jensen.) 


1. Ferming: During this initial stage, members get acquainted with each other and understand the 
scope of the project. They begin to establish ground rules by trying to find out what behaviours 


are acceptable with respect to both the project (what role they will play, what. performance 



















o Team members initial greetings. 
* Orientation to the project and inductions. 
e Team members ‘checking’ each-other out. 
è Best behaviours usually displayed. 








* Project problem and vision questioned 

e Conflict over project roles and responsibilities, 

* Personality conflict, power plays and other social behaviours emerge 
e Technical and process decision made ane questioned 








e Focus on the project 

e Focus on achieving the assigned work packages 

e Roles becoming established, with minor conflict 

* General movement together as a teamto the project goals 











+ Work is being produces, deliverables are being met 

e Project manager leverages group rewards to keep the team motivated 

e Team in the main is 'getting-on’ and working together as a team 

e Performing as a well-oiled unit | Regression 








> Individuals released from the project 

* Project goals are accomplished and team rewarded 
* Closure and goodbyes protocol carrie@ out 

e New assignments taken-up by the individuals 
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expectations are) and interpersonal relations (who’s really in charge). This stage is completed 
once members begin to think of themselves as part of a group. 


2. Storming: As the name suggests, this stage is marked by a high degree of internal] conflict. 
Members accept that they are part of a project group but resist the constraints that the project 
and group put on their individuality. There is conflict over who will control the group and how 
decisions will be made. As these conflicts are resolved, the project manager's leadership becomes 
accepted, and the group moves to the next stage. 


3. Norming: The third stage is one in which close relationships develop and the group demonstrates 
cohesiveness. Feelings of camaraderie and shared responsibility for the project are heightened. 
The norming stage is complete when the group structure solidifies and the group establishes a 
common set of expectations about how members should work together. 


4. Performing: The team-operating structure at this point is fully functional and accepted. Group 
energy has moved from getting to know each other and how the group will work together, to 
accomplishing the project goals. 


a 


Adjourning: For conventional work groups, performing is the last stage of their development. 
However, for project teams, there is a completion stage: during this stage, the team prepares for 
its own disbandment. High performance is no longer a top priority. Instead, attention is devoted 
to wrapping up the project. Member responses will vary during this stage. Some members will 
be upbeat and will bask in the project team’s accomplishments. Others may feel down over the 
loss of camaraderie and (potentially) loss of friendships they have gained with people during the 
project's life. 


Tuckman’s model has several implications for those working on project teams. The first is that. 
the model provides a framework for the group to understand its own development. Project managers 
often find it useful to share this model with their teams. It can help members accept the tensions of 
the ‘Storming’ stage and direct their focus to moving towards the more productive stages. Another 
implication is that it stresses the importance of the ‘Norming’ stage, which contributes significantly to 
the level of productivity experienced during the ‘Performing’ stage. 

It should be noted that teams can (and often do) regress to prior stages of the model. For example, 
when a new team lead is brought into the project team, the team may regress, albeit temporarily, 
into the ‘Forming’ or ‘Storming’ stages of the model. Project managers, as we shall see, have to take 
an active role in shaping group norms that will contribute to ultimate project success. The project 
manager must be able to quickly identify unacceptable behaviours and intervene with corrective 
actions. 


14.9.3 Ensuring clarity of roles and responsibilities 


A number of project artefacts have been discussed in this chapter. As illustrated in Table 14.1, the 
RASCI Matrix gives the project manager an opportunity to bring all the governance aspects of project 
roles together. The RASCI clearly describes the business rules and/or the decisions particular roles are 
responsible/accountable for, in a matrix format. 

The letters in RASCI Matrix stand for: 


m Responsible: Who is primarily responsible for making sure the rule or decision is enacted? (There 
can be multiple people involved in taking responsibility.) 


E Accountable: The person who has sole accountability for ensuring the decision/rule is enacted. 
(There should only be one person or group in this role.) 


™ Supports: The people who are to support the accountable/responsible person. They could, for 
example, be providing information. 


CHAPTER 14 THE PROJECT MANAGER AND PROJECT TEAMS 


Table 141 RASCI Matrix 


Business rule/decision Category Role 

Project manager | Project team 
Approval of purchase orders > $50 K Procurement A R | 
Approval to move from one stage Governance R S R A 


(gate review) to the next. 


E Censulted: Here, you are seeking to identify the people who must be consulted. This may be the 
enduser or customer, for example. 


E Infermed: This refers to the people who must be informed of the decision (or rule) outcome. 
Again, these could be persons who are external to the project or the project team. 


The project manager typically uses a spreadsheet to build the RASCI Matrix as illustrated in Table 14.1. 
The following steps help to define each row in a RASCI Matrix: 


Step 1: Define all roles within the project (e.g. project manager, project team, project sponsor, 
change contro] board, SMEs). 

Step 2: Capture the business rule/decision (e.g. approval of purchase orders > $5@ thousand). 

Step 3: Categorise the rule (this makes for easier filtering of the rules later on). 


Step 4: Allocate the RASCI letters across the roles as appropriate (in this case, the project 
manager is Accountable, the project team is Responsible and the Sponsor is Informed). 


Remember, there can only be one ‘A’ or Accountable person/group, but roles can have multiple 
allocations. For example, a role can be both Accountable and Responsible, or Consulted and Supports. 
The RASCI can provide a useful tool to help ameliorate team conflict where there is dispute over ‘who 
does what’, or ‘who makes which decisions’, in the project. 


14.9.4 Situational factors affecting team development 


Experience and research indicate that highperformance project teams are much more likely to 
develop under the following conditions: 


There are more than seven or fewer than two members per team. 

Members volunteer to serve on the project team. 

Members serve on the project from beginning to end. 

Members are assigned to the project full time. 

Members are part of an organisational] culture that fosters cooperation and trust. 
Members report solely to the project manager. 

Allrelevant functional areas are represented on the team. 


The project involves a compelling objective. 


Members are located within conversational] distance of each other. 


In reality, it is rare that a project manager is assigned a project that meets all of these conditions. 
For example, many projects’ requirements dictate the active involvement of more than 1® members and 
may consist of a complex set of interlocking teams comprising more than 100 professionals. In many 
organisations, functional managers or central staffing offices assign project members, with little input 
from the project manager. To optimise resource utilisation, team member involvement may be part 
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time and/or participants may move in and out of the project team on an ‘asneeded’ basis. In the case 
of ad hoc task forces, no member of the team works full time on the project. In many corporations a 
‘not invented here (NIH)’ culture exists that discourages collaboration across functional boundaries. 

Team members often report to different managers and, in some cases, the project manager will 
have no direct input over team members’ performance appraisals and advancement opportunities. 
Key functional areas may not be represented during the entire duration of the project but may only 
be involved in a sequential manner. Not all projects have a compelling objective. It can be hard to 
get members excited about mundane projects such as a simple product extension or a conventional 
apartment complex. Finally, team members are often scattered across different corporate offices 
and buildings or, in the case of a virtual project, across the entire globe. It is important for project 
managers and team members therefore to recognise the situational constraints they are operating 
under, and to do the best they can within these constraints. It would be naive to believe that every 
project team has the same potential to evolve into a highperformance team. Under lessthan-ideal 
conditions, it may be a struggle just to meet project objectives. Ingenuity, discipline and sensitivity to 
team dynamics are therefore essential in maximising the performance of a project team. 


14.9.5 Building high-performance project teams 


Project managers play a key role in developing high-performance project teams. They recruit members, 
conduct meetings, establish a team identity, create a common sense of purpose or a shared vision, 
manage a reward system that encourages teamwork, orchestrate decision-making, resolve conflicts 
that emerge within the team and rejuvenate the team when energy wanes (see Figure 14.8). Project 
managers take advantage of situational factors that naturally contribute to team development, while 
improvising around those factors that inhibit team development. In doing so, they exhibit a highly 
interactive management style that exemplifies teamwork and, as discussed in the previous chapter, 
manage the interface between the team and the rest of the organisation. 

When building highperformance project teams, as with all factors in project management, we 
need to consider the integrative aspects of human resource management. The fellowing are examples 
of questions a project manager ought to consider when building the team: 


E DolIneed to budget for team-building activities? 


mg What is the impact to the project schedule? 


mg What is the best way to reward the project team (both financial and nonfinancial)? 


14.9.6 Generational theory and project teams 


Whether referred to as ‘generational theory’, ‘multigenerational teams’ or ‘age diversity’, workplaces 
today are often rich melting pot of differing cultures, ages and genders. The project manager needs 


Conduct project meetings 


Establish team identity 
Create a shared vision 


Build a reward system 
Manage decision-making 
Manage conflict 
Rejuvenate the project team 
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to understand the dynamics of the project team from a personality perspective, and also be able to 
consider many other varied dimensions. For example, when a younger, relatively inexperienced person 
is recruited into a highly experienced project team, how does this change team dynamics? Keeping an 
open mind and sense of positivity about the younger person can alleviate tensions—almost everyone 
we encounter at work can teach us something new or provide a different perspective. 

Fresh ideas that are brought to the table could invigorate a stale environment and new tools and 
ways of communicating should be embraced. Try asking rhetorical questions to explore the potential 
of tools and skills that may, at first, seem alien to some project environments. For example, how might 
social media technologies assist us in achieving or promoting the outcomes of the project? 

If the younger person will be supervising older team members, prepare the team to accept the 
person as the boss. Give the person the support they need; after all, it was your decision to employ 
that person in the role of supervisor or manager, therefore you must have confidence in their ability. 
Your role as project manager is to achieve the project’s success (and ultimately your own success). 
Consider putting into place suitable coaching and mentoring arrangements for anyone in the team 
who needs coaching and mentoring. 

Younger supervisors or managers should also openly show respect for the wealth of knowledge and 
experience that older team members may have. Remember that even though some older generations 
may be battle-hardened, they can nonetheless also be very adaptable and open to new ideas. Bringing 
in a new technology or theory may greatly assist the project, but a ‘gung-ho’ approach often fails. 
In this instance, it is better to make a case for change and provide examples showing where the 
technology has worked with other projects. 

Understanding that. some generations prefer faceto-face time, as opposed to electronic forms of 
communicating, means that provision should be made for in-person communication, as well as email, 
tweets and instant messaging. Of course, whether faceto-face or electronic communication takes 
place, it is important to be considerate of what is being communicated, when and to whom. Accept 
that meetings have a purpose and that meeting people and building relationships in business usually 
involves a faceto-face activity (or a telephone call when communicating with more remotely located 
employees or stakeholders). 

Intergenerational differences are frequently brought to the fore in workplaces. The current 
economic climate means there has been an increase in the number of mature-aged workers seeking 
to stay in or return to work. In specialist areas, personnel may be called back from retirement due to 
resource shortages. A good project manager must be aware of any generational differences, but also 
of cultural differences. For example, in the Middle East, the working week typically starts on a Sunday 
and ends on a Thursday (Friday being the Muslim holy day). In China, the way of business is ‘Guanxi’, 
meaning ‘relationships’ or ‘connections’. Guanxi can best be described as a network of elaborate 
relationships that promote trust and cooperation. Establishing Guanxi in a sincere, supportive manner, 
based on mutual respect, is a fundamental aspect of Chinese culture and of doing business in China. 
In Japan, ‘Wa’ (harmony), ‘Kao’ (the notion of ‘face’ and personal pride) and ‘Omoiyari’ (empathy and 
loyalty) are encouraged in society, but this is also carried through into the Japanese business culture. 
When using resources from other countries, make sure there is a general awareness throughout 
the project of any cultural needs and expectations that need to be met. After all, it is a truly global 
envirenment that projects operate within today. 


14.9.7 Orchestrating the decision-making process 


Most project decisions do not require a formal meeting to be held to discuss alternatives and 
determine solutions. Instead, decisions are made in real time as part of the daily interaction patterns 
between project managers, stakeholders and team members. For example, as a result of a routine 
‘how's it going?’ question, a project manager discovers that a mechanical engineer is stuck trying 
to meet the performance criteria for a prototype he is responsible for building. The project manager 
and engineer go down the hallway to talk to the designers, explain the problem and ask what, if 
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anything, can be done. The designers distinguish which criteria are essential and which ones they 
think can be compromised. The project manager then checks with the marketing group to make sure 
these modifications are acceptable. They agree with all but two of the modifications. The project 
manager goes back to the mechanical engineer and asks whether the proposed changes would help 
solve the problem. The engineer agrees. Before authorising the changes he calls the project sponsor, 
reviews the events, and gets the sponsor to sign off on the changes. This is an example of how, by 
practising MBWA (management by wandering around), project managers can consult team members, 
solicit their ideas, determine optimum solutions, and create a sense of involvement that builds trust 
and commitment to decisions. 

Projects can encounter problems that require the collective decision-making and wisdom of 
team members, as well as relevant stakeholders. Group decision-making should be used when it will 
improve the quality of important decisions. This is often the case with complex problems that require 
the input of a variety of different specialists. Group decisionmaking should also be used when strong 
commitment to the decision is needed and there is a low probability of acceptance if only one person 
makes the decision. Participation is used to reduce resistance and secure support for the decision. 
Group decision-making would be utilised for example, to deal with controversial problems that could 
have a major impact on project activities, or when trust is low within the project team. Some guidelines 
for managing group decision-making are provided below. 


FACILITATING GROUP DECISION-MAKING 

Project managers play a pivotal role in guiding the group decision-making process. They must re- 
mind themselves that their job is not to make a decision, but. to facilitate discussion within the group 
so that the team reaches a consensus on the best possible solution. Consensus within this context 
does not mean that everyone supports the decision 100 per cent, but that they all agree on what the 
best solution is, under the circumstances. Facilitating group decisionmaking essentially involves 
four major steps. Each step is briefly described below and suggestions are provided for how to man- 
age the process. 


1. Preblem identi ficatien: The project manager needs to be careful not to state the problem in terms 
of choices (e.g. should we do X or Y?). Rather, the project manager should identify the underlying 
problem to which these alternatives, and probably others, are potential solutions. This allows 
group members to generate alternatives, not just choose among them. One useful way of defining 
problems is to consider the gap between where a project is (i.e. the present state) and where 
it should be (the desired state). For example, the project may be four days behind schedule, 
or it could be that the prototype weighs two pounds more than the specifications. Whether the 
gap is small or large, the purpose is to eliminate it. The group must find one or more courses 
of action that will change the existing state into the desired one. If defensive posturing arises 
during the ‘problem identification’ discussion, then it may become appropriate to postpone the 
problemsolving step, if possible. This allows for emotions to subside and members to gain a fresh 
perspective on the issues involved. 


2. Generating alternatives: Once there is general agreement as to the nature of the problem(s), 
the next step is to generate alternative solutions. If the problem requires creativity, then 
brainstorming is commonly recommended: the team generates a list of possible solutions, 
writing these up on a flipchart or whiteboard, and runs through each suggestion one by one, as 
a collective. Before this takes place, the project manager would first ban criticism and would 
remind participants to be respectful of each other's ideas. Members would be encouraged to 
piggyback on others’ ideas by extending them, or by combining ideas to form a new idea. The 
object is to create as many alternatives as possible, no matter how outlandish they may appear to 
be. Some project managers report that for really tough problems, they have found it beneficial to 
conduct such sessions away from the normal work environment; a change of scenery (to neutral 
ground) often appears to stimulate fresh creativity. 
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3. Reaching a decision: The next step is to evaluate and assess the merits of alternative solutions. 
During this stage it is useful to have a set of criteria for evaluating the merits of different 
solutions. In many cases, the project manager can draw upon the priorities for the project and 
have the group assess each alternative in terms of its impact on cost, schedule and performance 
as well as reducing the problem gap. For example, if time is critical, then the solution that solves 
the problem as quickly as possible would be chosen. 


During the course of the discussion, the project manager attempts to build consensus among the 
group. This can be a complicated process. Project managers need to provide periodic summaries 
to help the group keep track of its progress. They must protect those members who represent 
the minority view and ensure that such views get a fair hearing. They need to guarantee that 
everyone has an opportunity to share opinions and no one individual or group dominates the 
conversation. (It may be useful to bring a twominute timer along and use this to regulate ‘air 
time’.) When conflicts occur, managers need to apply some of the ideas and techniques that are 
discussed in the next section. Project managers need to engage in consensustesting to determine 
what points the group agrees on and what remains as sources of contention. They need to be 
careful not to interpret silence as agreement and need to confirm agreement by asking direct 
questions. Ultimately, through thoughtful interaction, the team reaches a ‘meeting of the minds’ 
as to what solution is best for the project. 


Remember, there is a difference between majority and consensus in a team decision-making 
environment. For example, if a team of eight people decide to move forward on a matter but only 
six of the eight agree, the team could leave the room in one of two states: 


(a) If a majority decision-making ground rule was practised, then six people would leave the 
room singing the praises of the decision while the other two could be in a more negative state 
and may not openly support the decision (e.g. when asked about it outside the room). 


(b) If a consensus decision-making ground rule was practised, then the project manager would 
press home that even though there may have been some initial disagreements in the room, 
everybody has now agreed to support this particular decision so as to move forward in a 
positive manner. When asked outside the room on the decision made, everyone would equally 
and positively support the decision made. 


4. Follow-up. Once the decision has been made and has been implemented, it is important for the 
team to find the time to evaluate its effectiveness. If the decision failed to provide the anticipated 
solution, then the reasons as to why this has occurred should be explored and the lessons-learned 
added to the collective memory bank of the project team for future reference. 


14.10 MANAGING PROJECT TEAMS 


The energy and drive of teams is captured in the term ‘synergy’, which is derived from the Greek word 
sunergos (‘working together’). Synergy perhaps can best be seen on a football pitch, or ina relay team 
where teammates play as one to defeat a foe. Although less visible than in team sports, positive and 
negative synergy can often be both observed and felt in the daily operations of project teams. Here is 
a description from one team member we interviewed about this phenomenon: 


‘Instead of operating as one big team we fractionalised into a series of subgroups. The 
marketing people stuck together, as well as the systems guys. A lot of time was wasted gossiping 
and complaining about each other. When the project started slipping behind schedule, 
everyone started covering their tracks and trying to pass the blame on to others. After a while 
we avoided direct conversation and resorted to email. Management finally pulled the plug and 
brought in another team to salvage the project. It was one of the worst project management 
experiences in my life.’ 
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This same individual] (fortunately) was also able to recount a more positive project team experience 
they had had: 


There was a contagious excitement within the team. Sure we had our share of problems and 
setbacks, but we dealt with them straight on and, at times, were able to do the impossible. We 
all cared about the project and looked out for each other. At the same time we challenged each 
other to do better. It was one of the most exciting times in my life. 


It is interesting to note that the following set of characteristics is commonly associated with high- 
performing teams that exhibit positive synergy: 


1. The team shares a sense of common purpose, and each member is willing to work towards 
achieving project objectives. 

2. The team identifies individual talents and expertise and uses them, depending on the project’s 
needs at any given time. At these times, the team willingly accepts the influence and leadership of 
the members whose skills are relevant to the immediate task. 

3. Roles are balanced and shared to facilitate both the accomplishment of tasks and feelings of 
group cohesion and morale. 

4. The team exerts energy towards problem-solving rather than allowing itself to be drained by 
interpersonal issues or competitive struggles. 


a 


Differences of opinion are encouraged and freely expressed. 


6. To encourage risktaking and creativity, mistakes are treated as opportunities for learning rather 
than reasons for punishment. 


7. Members set high personal standards for performance and encourage each other to realise the 
objectives of the project. 

8. Members identify with the team and consider it an important source of both professional and 
personal growth. 


High-performing teams become champions, create breakthrough products, exceed customer 
expectations, and get projects done ahead of schedule and under budget. They are bonded together by 
mutual interdependency and a common goal or vision. They trust each other and exhibit.a high level 
of collaboration. 


14.10.1 Managing project reward systems 


Project managers are responsible for managing the reward system that encourages team performance 
and extra effort. One advantage they have is that often project work is inherently satisfying, whether it 
is manifested in an inspiring vision or a simple sense of accomplishment. Projects provide participants 
with a change of scenery, a chance to learn new skills, and an opportunity to break out of their 
departmental cocoon. 

Most project managers we talk to advocate the use of group rewards. Because most project work 
is a collaborative effort, it only makes sense that the reward system would encourage teamwork. 
Recognising individual members, regardless of their accomplishments, can distract from team unity. 
Project work is highly interdependent, so it can become problematic to distinguish who truly deserves 
additional credit. Cash bonuses and incentives need to be linked to project priorities. It makes no 
sense to reward a team for completing its work early, if controlling cost was the number one priority. 
One of the limitations of lumpsum cash bonuses is that all too often they are consumed by the 
household budget to pay the dentist or mechanic. To have more value, rewards need to have lasting 
significance. Many companies convert cash into holiday rewards (sometimes with corresponding time 
off work). For example, one firm rewarded a project team for getting the job done ahead of schedule 
with a four-day, allexpenses-paid trip to Walt. Disney World for the members’ entire families. That, 
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holiday will not only be remembered for years, it also acknowledged spouses and the team members’ 
children who, in a sense, also contributed to the project’s success. Similarly, other firms have been 
known to give members home computers and entertainment centres. Wise project managers negotiate 
a discretionary budget so they can reward teams who surpass milestones with gift certificates (e.g. 
to popular restaurants) or tickets to sporting events. Impromptu pizza parties and barbecues are also 
positive ways to celebrate key accomplishments. 

Sometimes, project managers have to use negative reinfercement to motivate project performance. 
For example, Ritti (1982) recounts the story of one project manager who was in charge of the 
construction of a new, state-oftheart manufacturing plant. His project team was working with a 
number of different. contracting firms. The project was slipping behind schedule, mostly because of 
a lack of cooperation among the different players. The project manager did not have direct authority 
over many of the key people, especially the contractors from other companies. He did, however, 
have the freedom to convene meetings at his convenience. So, the project manager instituted daily 
‘coordination meetings’, which all principals involved in the project were required to attend at 6.30 
am. The meetings continued for about two weeks until the project got back on schedule. At that time 
the project manager announced that the next 6.30 am meeting was cancelled (and no further meetings 
were needed as the project did not slip behind schedule again). 

While project managers tend to focus on greup rewards, there are times when they need to reward 
individual performance. This is done not only to compensate extraordinary effort, but also to signal 
to the others what exemplary behaviour looks like. Some examples of rewards that. can be used to 
motivate and recognise individual contributions include: 


E Letters ef commendatien: While project managers may not have responsibility for their team 
members’ performance appraisals, they can write letters commending their project member's 
performance. These letters can be given directly to the individual and/or to the worker's 
supervisor(s) (and can be placed in their personnel files to document their positive contribution 
towards the project/the organisation). 


m Public recegnitien fer eutstanding werk: Outstanding workers should be publicly recognised for 
their efforts. Some project managers begin each status review meeting with a brief mention of 
those project workers who have exceeded their project goals. 


E Jeb assignments: Good project managers recognise that, while they may not have much budgetary 
authority, they do have substantial control over ‘who does what, with whom, when and where’. 
Good work should be rewarded with desirable job assignments. Managers should be aware of 
team member preferences and, when appropriate and possible, seek to accommodate these. 


m Flexibility: If done judiciously, a degree of flexibility (being willing to make exceptions to rules) 
can be a powerful reward—for example, allowing members to work at home when a child is sick, 
or excusing a minor imprudence as a learning opportunity, can engender long-lasting loyalty. 


We reiterate, however, that individual rewards should be used judiciously, and the primary emphasis 
should be on group incentives. Nothing can undermine the cohesiveness of a team more than members 
beginning to feel that others are getting special treatment (favouritism) or that they are being treated 
unfairly. Camaraderie and collaboration can quickly vanish, only to be replaced by bickering and 
obsessive preoccupation with group politics. Such distractions can absorb a tremendous amount of energy 
that otherwise would be directed towards completing the project. Individual rewards typically should be 
used only when everyone in the team recognises that a member is deserving of special recognition. 


14.10.1 Managing conflict within the project 


Disagreements and conflicts naturally emerge within a project team during the life of a project. 
Participants will disagree over priorities, allocation of resources, the quality of specific work, 
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solutions to discovered problems and so forth. Some conflicts support the goals of the group and 
improve project performance. For example, two members may be locked in a debate over a design 
trade-off decision involving different features of a product. They argue that their preferred feature 
is what the primary customer truly wants. This disagreement may force them to talk to or get more 
information from the customer, with the result that they realise neither feature is highly valued, and 
the customer wants something else. On the other hand, conflicts can also hinder group performance. 
Initial disagreements can escalate into heated arguments with both parties storming out of the room 
and refusing to work together. 


14.10.2 Encouraging functional (healthy) conflict 


The demarcation between functional and dysfunctional conflict is neither clear nor precise. In 
one team, members may exchange a diatribe of four-letter expletives and eventually resolve their 
differences. Yet in another project team, such behaviour would create irreconcilable divisions, 
and would prohibit the parties from ever working together productively again. The distinguishing 
criterion is how the conflict affects project performance, not how individuals feel. Members can be 
upset and dissatisfied with the interchange, but as long as the disagreement. furthers the objectives 
of the project, then the conflict is functional. Project managers should recognise that conflict is an 
inevitable (and even a desirable) part of project work; the key is to encourage functional conflict and 
manage dysfunctional conflict. 

A shared vision can transcend the incongruities of a project and establish a common purpose 
to channel debate in a constructive manner. Without shared goals, there is no common ground for 
working out differences. In the previous example involving the design trade-off decision, when 
both parties agreed that the primary goal was to satisfy the customer, there was a basis for more 
objectively resolving the dispute. Therefore, agreeing in advance which priority is most important— 
cost, schedule or scope—can help a project team decide which response is most appropriate. 

Sometimes it’s not the presence of conflict but the absence of conflict that is the problem. 
Sometimes, as a result of compressed time pressures, self-doubt and the desire to preserve team 
harmony, members are reluctant to voice objections. This hesitation robs the team of useful information 
that might lead to better solutions and the avoidance of critical mistakes. Project managers need to 
encourage healthy dissent in order to improve problemsolving and innovation. They can demonstrate 
this process by asking tough questions and challenging the rationale behind recommendations. They 
can also orchestrate healthy conflict by bringing in people with different. points of view to critical 
meetings. Project managers can legitimise dissent within the team by designating someone to play 
the role of ‘devil's advocate’ or by asking the group to take 15 minutes to come up with all the reasons 
the team should not pursue a course of action. Functional conflict plays a critical role in obtaining a 
deeper understanding of the issues and coming up with the best decisions possible. 

One of the most important things project managers can do is mode] an appropriate response 
when someone disagrees or challenges their ideas. They need to avoid acting defensively and instead 
encourage critical debate. They should exhibit effective listening skills and summarise the key issues 
before responding. They should check to see if others agree with the opposing point of view. Finally, 
project managers should value and protect dissenters. Organisations have a tendency to create too 
many ‘yes men’ but the emperor needs to be told when he doesn’t have any clothes on! 


14.10.3 Managing dysfunctional conflict 


Managing dysfunctional conflict is a much more challenging task than encouraging functional 
conflict. First, dysfunctional conflict is hard to identify. A manager might have two highly talented 
professionals who hate each other’s guts, but in the heat of competition they produce excellent results. 
Is this a pleasant situation? No. Is it functional? Yes, as long as it. contributes to project performance. 
Conversely, sometimes functional conflict degenerates into dysfunctional conflict. This change occurs 
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when technical disagreements evolve into irrational personality clashes or when failure to resolve an 

issue causes unnecessary delays in critical project work. 

The second major difficulty managers face is that there is often no easy solution to dysfunctional 
conflict. Project managers have to decide among a number of different strategies to manage it. Here 
are five possibilities: 

1. Mediate the cenflict: The manager intervenes and tries to negotiate a resolution by using 
reasoning and persuasion, suggesting alternatives and the like. One of the keys is trying to find 
common ground. In some cases the project manager can make the argument that the win-lose 
interchange has escalated to the point that it has become lose—lose for everyone and now is the 
time to make concessions. 


2. Arbitrate the cenflict. The manager imposes a solution to the conflict after listening to each 
party. The goal is not to decide who wins but to have the project win. In doing so, it is important 
to seek a solution that allows each party to save face; otherwise the decision may provide only 
momentary relief. 


3. Centrel the cenflict. Reducing the intensity of the conflict by smoothing over differences or by 
interjecting humour is an effective strategy. If feelings are escalating, the manager can adjourn 
the interaction and hope cooler heads prevail the next day. If the conflict continues to escalate, 
project assignments may need to be rearranged (if possible) so the two parties don’t have to work 
together. 


4. Accept it. Insome cases, the conflict will outlive the life of the project and, though a distraction, it 
is something the manager has to live with. 


5. Eliminate the cenflict. Sometimes the conflict has escalated to the point that it is no longer 
tolerable. In this case the manager removes the members involved from the project. If there is a 
clear ‘villain’ then only that person should be removed. If, as is often the case, both parties are at 
fault, then it would be wise if possible to remove both individuals from the project. Their removal 
would give a clear signal to the others on the team that this kind of behaviour is unacceptable. 


Project managers establish the foundation for functional conflict by establishing clear roles and 
responsibilities, developing common goals or a shared vision, and using group incentives that reward 
collaboration. Project managers have to be adroit at reading body language to identify unspoken 
disagreement. They also have to keep in touch with what is going on in a project to identify small 
problems that might escalate into big conflicts. Welltimed humour and redirecting the focus to what 
is best for the project can alleviate some of the interpersonal tensions that are likely to flare up ona 
project team. 

The nominal group technique (NGT) process can be a useful tool when trying to gain team 
agreement on a number of issues. By applying the NGT process, the team can generate a prioritised 
list of issues that need to be addressed. 

Many other instruments can be deployed to assist in diagnosing team conflict. Some commonly 
encountered ones include: 


E Team Management Systems (TMS): A system of work-based, research-proven assessments and 
feedback instruments that supports individuals, teams and organisations to effect positive and 
lasting change and achieve higher performance in the workplace (www.tms.com.au). 


m Myers-Briggs Type Indicater®: A tool for helping to gain a basic understanding of personality 
type (www.myersbriggs.org). 
E Belbin®Team Roles: Reports that can help to select/develop high-performing teams, raise self- 


awareness and increase personal effectiveness (www.belbin.convrte.asp). 


m Other teels: Disc360° (www.everythingdisc.com/Home.aspx) and The Colour Wheel (www.inside- 
inspiration.com.au/factsheets/insights-discove r ypersonal-effectivenessprogramfactsheet. pdf). 
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Using team performance and personality tools, such as those listed above, can help a project 
manager not only to identify personality types within their project team, but they can also help them 
to ascertain strategies that can be employed to foster positive team and individual interactions. For 
example, TMS has a particular focus on team dynamics and provides suggestions for how people in 
conflict could work with each other. TMS is debriefed on two levels: an individual level report, and a 
facilitated team debrief to all members of the team. 


14.10.4 Rejuvenating the project team 


Over the course of a long project, a team sometimes drifts off course and loses momentum. If this 
happens, the project manager needs to swing into action to realign the team with the project’s objectives 
and step on the pedal. There are both formal and informal ways of doing this. Informally, the project 
manager can institute new rituals like the ‘toy cockroaches’ (as discussed earlier) to reenergise a 
team. On one project that was experiencing rough-going, the project manager stopped work and took 
the team bowling to relieve frustrations. Another option is to have the project sponsor give a ‘pep talk 
to the troops’. In other cases, a friendly challenge can reinvigorate a team. For example, one project 
sponsor offered to cook a fivecourse meal if the project got back on track and hit the next milestone. 

Sometimes, more formal action needs to be taken: the project manager may recognise the need 
for a team-building session devoted to improving the work processes of the team. This meeting is 
particularly appropriate if they sense that the team is approaching a transition point in its development. 
The goal of such a session is to improve the project team’s effectiveness through better management. 
of project demands and group processes. It is an inward look by the team at its own performance, 
behaviour and culture, for the purpose of eliminating dysfunctional behaviours and strengthening 
functional ones. The project team critiques its performance, analyses its way of doing things, and 
attempts to develop strategies to improve its operation. 

As important problems are discussed, alternatives for action are developed. The team-building 
session concludes by deciding on specific action steps for remedying problems and setting target 
dates for ‘who will do what, when’. These assignments can be reviewed at project status meetings or 
at a special follo w-up session. 

It has become fashionable to link team-building activities with outdoor experiences. The outdoor 
experience—whether it is hiking or canoeing, for example—places group members in a variety of 
physically challenging situations that must be mastered through teamwork, not individual effort. By 
having to work together to overcome difficult. obstacles, team members are supposed to experience 
increased self-confidence, more respect for another's capabilities and a greater commitment. 
to teamwork. No empirical data is available to support such exotic endeavours, other than the 
enthusiastic support of the participants. Such activities are likely to provide an intense common 
experience that may accelerate the social development of the team. Such an investment of time and 
money communicates the importance of teamwork and is considered by some as a perk of being on the 
project. At the same time, unless the lessons from these experiences can be immediately transferred to 
actual project work, their significance is likely to vanish. 


14.10.5 Conducting project meetings 
The first project ‘kick-off’ meeting is critical to the early functioning of the project team. According 
to one veteran project manager: 


The first team meeting sets the tone for how the team will work together. If it is disorganised, 
or becomes bogged dow n with little sense of closure, then this can often become a self-fulfilling 
prophecy for subsequent group work. On the other hand, if it is crisply run, focusing on real 
issues and concerns in an honest and straightforward manner, members come away excited 
about being part of the project team. 
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There are typically three objectives project managers try to achieve during the first meeting of the 
project team. The first is to provide an overview of the project, including the scope and objectives, the 
general schedule, method and procedures. The second is to begin to address some of the interpersonal 
concerns captured in the team development model: Who are the other team members? How will I fit in? 
Will I be able to work with these people? The third and most important objective is to begin to model 
how the team is going to work together to complete the project. The project manager must recognise 
that first impressions are important; their behaviour will be carefully monitored and interpreted by 
team members. This meeting should serve as an exemplary role model for subsequent meetings and 
reflect the leader’s style. 

The meeting itself comes in a variety of shapes and forms. It is not uncommon in major projects 
for the kick-off meeting to involve one or two days, often at a remote site, away from interruptions. 
This retreat provides sufficient time for preliminary introductions, for beginning to establish ground 
rules and for defining the structure of the project. One advantage of off-site kick-off meetings is that 
they provide ample opportunity for informal interaction among members during breaks, meals and 
evening activities; such informal interactions are critical to forming positive working relationships. 
However, many organisations either do not have the luxury of holding elaborate retreats or the scope 
of the project and the level of involvement required by different participants does not warrant such 
an investment. of time. In these cases, the key operating principle should be KISS (Keep it simple, 
stupid!—a design principle coined within the US Navy in 1960). Too often, when constrained by 
time, project managers try to accomplish too much during the first meeting, and in doing so, issues 
do not get fully resolved and members come away with an ‘information headache’. The primary goal 
is to run a productive meeting, and objectives should be realistic given the time available. If the 
meeting is only one hour, then the project manager should simply review the scope of the project, 
discuss how the team was formed, and provide an opportunity for members to introduce themselves 
to the team. 


ESTABLISHING GROUND RULES 


Whether as part of an elaborate first meeting or during follow-up meetings, the project manager must 
quickly begin to establish operational ground rules for how the team will work together. These ground 
rules involve not only organisational and procedural issues, but also normative issues on how the 
team will interact with each other. Although specific procedures will vary across organisations and 
projects, some of the major issues that will need to be addressed include the following: 


PLANNING DECISIONS 


How will the Project Plan be developed? 

What tools will be used to support the project? 

Will a specific project management software package be used? If so, which one? 
Who will enter the planning information? 

What are the specific roles and responsibilities of all the participants? 

Who needs to be informed of decisions? How will they be kept informed? 

What is the relative importance of cost, time and performance? 

What are the deliverables of the projectplanning process? 

What format is appropriate for each deliverable? 


Who will approve and sign off at the completion of each deliverable? 


Who receives each deliverable? 
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TRACKING DECISIONS 


How will progress be assessed? 

At what level of detail will the project be tracked? 

How will team members get data from each other? 

How often will they get this data? 

Who will generate and distribute reports? 

Who needs to be kept informed about project progress, and how will they be informed? 


What content/format is appropriate for each audience? 


Meetings 

— Where will meetings be located? 

— What kind of meetings will be held? 
— Who willrun the meetings? 

— How will agendas be produced? 


— How will information be recorded? 


MANAGING CHANGE DECISIONS 


= How will changes be instituted? 
@ Who will have change approval authority? 


m How will plan changes be documented and evaluated? 


RELATIONSHIP DECISIONS 


What department or organisations will the team need to interact with during the project? 
What are the roles and responsibilities of each organisation (reviewer, approver, creator, user)? 
How will all involved parties be kept informed of deliverables, schedule dates, expectations, etc.? 


How will the team members communicate among themselves? 


What information will and won't be exchanged? 


Checklists like these are only a guide; items should be added or deleted as needed. Many of these 
procedures will have already been established by precedent and will only have to be briefly reviewed. 
For example, Microsoft® Project or Oracle® Primavera may be the standard software tool for planning 
and tracking. Likewise, a specific firm is likely to have an established format for reporting status 
information. How to deal with other issues will have to be determined by the project team. When 
appropriate, the project manager should actively solicit input from the project team members and 
draw upon their experience and preferred work habits. This process also contributes to their buying 
into the operational decisions. Decisions should be recorded and circulated to all members. 

During the course of establishing these operational procedures, the project manager, through word 
and deed, should begin working with members to establish the ‘norms’ for team interaction. Below are 
examples of some norms that researchers have found to be associated with highperformance teams. 


@ Confidentiality is maintained; no information is shared outside the team unless all agree to it. 


CHAPTER 14 THE PROJECT MANAGER AND PROJECT TEAMS 


@ Itis acceptable to be in trouble, but it is not acceptable to surprise others. Tell others immediately 
when deadlines or milestones will not be reached. 


There is zero tolerance for bullying a way through a problem or an issue. 
Agree to disagree, but when a decision has been made, regardless of personal feelings, move forward. 


Respect outsiders, and do not flaunt one’s position on the project team. 


Hard work does not get in the way of having fun. 


One way of making these norms more tangible is by creating a team charter that goes beyond the 
scope statement of the project and states in explicit terms the norms and values of the team. This charter 
should be a collaborative effort on the part of the core team. Project managers can lead by proposing 
certain tenets, but they need to be open to suggestions from the team. Once there is general agreement to 
the rules of conduct, each member signs the final document to symbolise commitment to the principles 
it contains. Unfortunately, in some cases, charters become a meaningless ritual because the charter 
is signed and filed away, never to be discussed again. To have a lasting effect, the charter has to be 
a legitimate part of the projectmonitoring system. Just as the team reviews progress towards project 
objectives, the team assesses the extent. to which members are adhering to the principles in the charter. 

Project managers play a major role in establishing team norms through personal example. If they 
freely admit mistakes and share what they have learned from the mistakes, other team members will 
begin to do the same. At the same time, project managers need to intervene when they believe such 
norms are being violated. They should talk to offenders privately and clearly state their expectations. 
The amazing thing about groups is that once a group is cohesive, with wellestablished norms, the 
members will often police themselves. For example, one project manager confided that his team had a 
practice of having a small beanbag present at every meeting. If any one member felt that.a colleague 
was shooting hot air or shading the truth, he or she was obliged to toss the beanbag towards the feet 
of the speaker! 


14.10.6 Managing subsequent project meetings 


The project kick-off meeting is one of several kinds of meetings required to complete a project. Other 
meetings include status report meetings, problemsolving meetings and audit meetings. Issues unique 
to these meetings will be discussed in subsequent chapters. For now, here are some general guidelines 
for running effective meetings. They speak directly to the person chairing the meeting. 


Start meetings on time—regardless of whether everyone is present. 

Prepare and distribute an agenda prior to the meeting. 

Identify an adjournment time. 

Periodically take time to review how effective previous meetings have been. 

Solicit recommendations and implement changes. 

Assign good recordkeeping. 

Review the agenda before beginning, and tentatively allocate time for each item. 

Prioritise issues so that adjustments can be made given time constraints. 

Encourage active participation of all members by asking questions instead of making statements. 
Summarise decisions and review assignments for the next meeting. 


Prepare and distribute a summary of the meeting to appropriate people. 


Recognise accomplishments and positive behaviour. 
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Table 14.2 Action tracking log 


Meeting date | Status (open/closed) | Meeting name | Action on | Raised by |Due date | Action details/tracking status 


Source: © 2018 Dr Neil Pearson 


Tracking the multitude of meetings that are typical for a project action can be facilitated by the use 
of a tracking spreadsheet (e.g. see Table 14.2). In practice, the action-tracking log would be displayed 
in the room (via a projector) and so it can also be shared via a web-conferencing system, with project 
team members who are remotely located. This would enable all meeting participants to see the actions, 
who they were assigned to, and their current status in a live format, as the meeting progressed. Once 
the meeting had concluded, the spreadsheet could be filtered (by meeting date and status) and the 
resulting contents cut and pasted into an email and sent out to all attendees. This active form of meeting 
action tracking ensures there is complete visibility and accountability for achieving actions. 

A useful technique, available via the Scrum framework, is the ‘sprint retrospective’ (refer to 
Chapter 3). This is where the previous reporting period is reviewed, and a focused discussion takes 
place based on the following questions: 


m What worked well? 

Æ What didn’t work well? 

m What could have been done better? 

m What lessons-learned were identified? 


The purpose of this review is to ensure that useful information is shared and that channels of 
communication remain open between the project team and the project manager in a process of 
‘continual learning’. Meetings are often considered an anathema to productivity, but this does not have 
to be the case. The most common complaint is that meetings last too long. Establishing an agenda and 
adjournment time therefore helps participants to budget their discussion time and provides a basis for 
expediting proceedings. Recordkeeping can be an unwelcome, tedious task. Utilising software tools 
to record decisions and information in real time can facilitate the communication process. Careful 
preparation and consistent application of these guidelines can make meetings a vital part of projects. 


14.10.7 Managing virtual project teams 


Building a highperformance project team from a mixture of parttime and fulltime members can be 
a challenging task. This is exacerbated when team members work offsite and cannot engage in face- 
to-face interactions. Such would be the case for a virtual project team in which the team members 
are geographically situated so that they may seldom, if ever, meet face to face as a team. For example, 
when one of the authors (Pearson) was projectmanaging a large back office consolidation of ICT 
systems at Oracle Corporation in the United States, he was in regular meetings with virtual team 
members in the United Kingdom, parts of Europe, and in Australia. Can you imagine the logistics of 
organising an ‘allhands’ meeting with multiple time-zone differences, cultures and availabilities? 
When team members are spread across different time zones and continents, opportunities for 
direct communication become constrained. Electronic communication, such as web-conferencing, 
email and teleconferencing, takes on more importance in virtual projects because this is the primary 
means of communication. Two of the biggest challenges involved in managing a virtual project team 
are developing trust and developing effective patterns of communication. Unlike when working as a 
traditional team, where members can see whether someone has done what they say they have done, 
virtual team members often have to depend on the word of distant members. At the same time, it can 
be difficult to trust someone whom you may have met only once or twice, or maybe not at all. (Now, 
of course, through Skype and other electronic communication mediums, people can see each other 
and read the nonverbals—for example, physical actions and voice tones.) Geographic separation 
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prohibits informal social interactions, which are often important in building camaraderie among team 
members. As one virtual team member complained, ‘You can’t have a beer together over the internet”. 

So how can a project manager facilitate the development of trust within a virtual team? If it is 
impossible to hold a facet o-face meeting at the beginning stage of team formation, a manager will 
need to orchestrate an exchange of social information (i.e. who everyone is and some personal 
working background information about each person) during the initial ‘virtual’ interchange. They 
also need to set clear roles for each team member. Ideally, specific tasks should be assigned to each 
member so everyone can make an immediate contribution to the project. Trust, within projects that 
necessitate a lot of virtual interaction, grows by fostering team member reliability, consistency and 
responsiveness. The project manager must consistently display enthusiasm and an actionorientation 
in all messages; this spirit will then hopefully spread to other team members. 

The second major challenge for managing a virtual project team is to establish effective patterns of 
communication. Emails and physical documents are great for communicating hard facts—but not the 
feelings that may lie behind these facts; nor do they allow for realtime communication. Conference 
calls and project chat rooms can help, but they also have their limitations. Videoconferencing is a 
significant improvement. over nonvisual electronic forms of communication. With the explosion of 
social media tools such as Skype, GoToMeeting and others, this has become far more accessible to 
organisations of all sizes. The maxim is match the technology to the communication need. Here are 
some guidelines developed by 3M for use on its distributed projects: 


E When to email: To distribute important information and news in a oneto-one or one-tomany 
frame of reference. 


E When to use electronic team boards (such as Yammer and Trello): To encourage discussion and 
flesh out diversity of opinion on issues. 


m When to videoconference: When you need to see each others’ face and expressions. This is 
important during the early stage of a project, when you are building relationships and developing 
a common understanding of what needs to be done. Use, again, when working on critical 
decisions and/or contentious issues. 


E When to use conference calls: When people in different locations are working with common 
documents, presentations, sketches and models. Use for status report meetings and to sustain 
social camaraderie. 


m When to fly: To build or repair trust. Use the travel budget to get all key players together early on 
to instil commitment to the goals of the project and engage in teambuilding activities. 


Even with the best communication system available, managers have to overcome the problem 
of time zone differences, cultural nuances and finding a convenient time for people to conference. 
The tips below can help to alleviate some communication problems and enhance the performance of 
virtual teams. 


1. Keep team members informed about how the overall project is going: Use shareware or develop a 
central access point (such as either a website or LAN account) to provide members with updated 
project schedules. Team members need to know where they fit into the big picture. 


2. Don't let team members ‘vanish’: Virtual teams often experience problems when trying to get in 
touch with each other. Use internetbased scheduling software to store members’ calendars. Call 
team members regularly, and make some of these calls social, not work related. 


3. Establish a code of conduct to avoid delays: Team members need to agree not only on what, when 
and how information will be shared, but also on how and when they will respond to it. Develop a 
priority system to distinguish messages that require immediate response from those with longer 
timeframes. 
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Table 14.3 Virtual team management tools* 


Category 
Conferencing 


Stakeholder management 


Team information-sharing 


| Purpose 


To facilitate voice, video and screen-sharing (of a computer 
screen) across multiple parties. 


Managing and sharing stakeholder information. These tools 
come from a customer relationship management (CRM) 
background but, in recent times have been applied to manage 
stakeholders in a project environment. 

These tools can be used to share information and provide social 
media style tools for team communications. Some of these tools 
offer a ‘private’ environment, which general social media tools 
do not. 


Tool 


www.webex.com 
www.gotomeeting.com 
www.gotowebinar.com 
www.gototraining.com 
www.skype.com 
https://www.eztalks.com 
www.salesforce.com/ 
www.zoho.com 
wwwstiger.com/crm/ 


www.atlassian.com/software/confluence/ 
www.yammer.com 

www.confluence.com 

www.trello.com 


Cloud-based project 


management environments 


Social media tools 


Google apps for business 
Microsoft teams 
www.dropbox.com 
www.box.net 


www.zoho.com/projects/ 
www.liquidplanner.com 
http://gantter.com 
www.aconex.com 
www.basecamp.com 


Useful tools that go beyond traditional project scheduling, 
to supplement the scheduling of activities to project team 
members. 


www.twitter.com 
www.facebook.com 
Google Hangouts 
https://slack.com 


Everyday social media tools that can be leveraged within the 
project environment. 


* Although the authers regularly use a wide selectien ef teels te achieve team eutcomes in a variety of different situatrens. the toels captured in this tale are included as 
indicative toels enly and the authers de net make any recemmendatiens as te which teols a prefect manager sheuld select, Preject managers must carry eut their ewn 
research te identify suitable alternatives that are the most appropriate and suitable fer their prefect and circumstances 


4. Establish clear nerms and pretecels fer surfacing assumptiens and cenflicts: Because 
most communication is nonvisual, project managers cannot watch body language and 
facial expressions to develop a sense of what is going on. They need to probe deeper when 
communicating, to encourage members to explain their viewpoints, actions and concerns more 
clearly. They must doublecheck comprehension. 


a 


Share the pain: Do not require everyone to conform to your time zone and preferences. Rotate 
meeting times so that. all team members have a turn working according to their clock. 


To some extent, managing a virtual project team is no different from managing a regular 
project team. The key is working within the constraints of the situation to develop effective ways 
for team members to interact and combine their talents to complete the project. There are many 
tools available to assist the project manager in a virtual environment; some of these are captured in 
Table 14.3. 


14.11 DISBANDING PROJECT TEAMS 


Saying goodbye at the end of a project for some team members can be a life-changing event. Over 
the life cycle of a project, team members often acquire new skills and abilities that make them more 
employable and more suited to other roles in, or beyond, the organisation. As the project moves 
towards making its final deliverables, progressively more and more team members will be leaving 
the project. Rarely does a large number of project team members leave all at. the same time. This 
progressive loss of team members will be noticed by those remaining in the team and will act as a 
stark reminder that they too will have to leave the project soon. This may affect the morale of the 
remaining team and the project manager must be able to identify this and step in to raise team spirits 
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and also keep the ‘spirit’ of the project alive through to final closure. Working relationships will have 
been made, trust gained, and a community will have been built, so the project manager must work 
diligently with individuals to manage their release from the project, in a controlled manner. When 
recruiting team members, a good, integrative project manager will: 


@ Establish an approximate timeframe for when the person is to be released from the project. 


@ Establish the conditions of the release; for example, if the person was contracted then the 
contract will be terminated according to the terms and conditions of the contract. If the person 
was internally sourced, they may be going back to their substantive position back in the business 
(this could potentially mean a drop in pay, which the human resources department may need to 
coach them to prepare for). 


@ Carry out the required performance agreement reviews, as required by the human resources 
department and company policies. This may include end-of-project/contract bonuses or other 
arrangements. 


Æ Carry out the required exit interviews, according to the human resources department and 
company policies. 


m Thank the team member for their contributions to the team. 


E Celebrate the successes of the team by holding a closure party to show the project manager, 
sponsor and organisation's gratitude for individual and team commitments in having completed 
the project successfully. 


Other considerations will include ensuring the core project team is present to be able to participate 
in the formal project closure meeting and in the postimplementation review. Both the project and the 
business will want to capture lessons-learned, for example. 

Remember, just as Tuckman and Jensen observed (refer to section 14.9.2), ‘Adjournment’ is 
recognised as a stage in the team development model. For a successful team, ‘Adjournment’ will be a 
positive experience; however, for individual team members, there can be asense of loss (almost a time 
of mourning) as farewells are said, and a whole new engagement has to be found. 


14.12 SERVANT LEADERSHIP 


The final section of this chapter takes the reader back to Chapter 3, where the role of Scrum master 
was discussed in detail. Scrum (and its Agile variants) promote the use of ‘servant’ leadership as the 
preferred style for managing the Scrum team (i.e. the product owner and the development team). Robert 
K Greenleaf formalised servant leadership into an approach that can be applied in any team environment: 


The servantleader is servant first . . . It begins with the natural feeling that one wants to 
serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply 
different from the person who is a leader first, perhaps because of the need to assuage an 
unusual power drive or to acquire mate rial possessions (Greenleaf 1970). 


The underlying principle therefore is that a servant leader leads by serving. In the case of Scrum 
(Agile and all variants) the Scrum master is the servant leader, among their other roles. The servant 
leader promotes social competency skills to elicit the best attributes out of the development team, product 
owner, and others around them. Some of the key traits of a servant leader would include the following. 


E Listening and understanding: If a Scrum master (or traditional project manager) takes the time 
to listen attentively to a person who is explaining a problem or issue they have encountered in 
a project, they are more likely to be able to help develop solutions. When in ‘listening mode’ a 
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Scrum master (or traditional project manager) is more easily able gain insights into what the 
problen/vsituation is, and is likely to provide advice based on ‘what works’. They are less likely to 
go into a ‘directing’ mode and therefore hopefully pursue a ‘coaching’ mode instead, from which 
the individual team member can learn (Greenleaf 1970). 


E Language and imagination: ‘Nothing is meaningful until it is related to the hearer’s own 
experience’ (Greenleaf 1970). Communicating needs to be just enough therefore to help the 
person make the leap from hearing to learning from experience. 


E Withdrawal: This means finding one’s optimum—learning when to ‘retreat’ (even if only for a 
moment), in order to reorient oneself. Withdrawal considers how to best make use of scarce 
resources and conserve energy, to deal with emergencies that will occur from time to time: ‘The 
servant-as-leader must constantly ask: How can I use myself to serve best?’ (Greenleaf 1970). 


E Acceptance and empathy: ‘The servant as leader always empathizes, always accepts the person 
but sometimes refuses to accept some of the person’s effort or performance as good enough’ 
(Greenleaf 1970). 


E Know the unknowable: Beyond conscious rationality, beyond academic intelligence, the servant 
leader needs to ‘have a sense for the unknowable and be able to foresee the unforeseeable’ 
(Greenleaf 1970). 


E Foresight: This is the central ethic of leadership—‘Prescience, or foresight, is a better than average 
guess about what is going to happen when in the future’ (Greenleaf 1970). It is the information gap 
between what we know (reports of information) and what may happen in the future. 


m Awareness and perception: This means picking up on the wider ‘sensory experience’ of the 
environment—the modern concept of being in the moment and being fully aware of one's 
surroundings. 


m Persuasion: Whether attempting to persuade a group or an individual, persuasion must be ‘gentle 
but clear and persistent persuasion’ which does not exert compliance through position power 
(Greenleaf 1970). 


E One action at a time: This is often the way that great things are achieved. 


E Conceptualising: Whether to a group or an individual, the servant leader needs to conceptualise 
and communicate thoughts and feelings in manner that makes them accessible to others. 


The elements above have been adapted from Greenleaf’s original text, to try to communicate 
the subtleties of how a servant leader behaves. For a traditional project manager, these can be hard 
to grasp and even harder to apply—how can one really ‘serve’ and ‘lead’ a project team? The PMI's 
Agile Practice Guide (2017b, p. 35) talks about a shift from ‘managing coordination’ to ‘facilitating 
coordination’. Facilitators encourage participation, shared understanding, shared responsibility (as it’s 
the team that brings the project over the line, not a single person), collaboration and communication 
(and the removal of bottlenecks or impediments). 

ScrumAlliance® promotes Greenleaf’s thinking and has managed to illustrate the essence of 
servant leadership (see https://www.projecttimes.com/articles/the-artand-science-of-servant-leader. 
inagile-scrum-world html). 

The trick for the Scrum master is to keep all proportions of the triangle equal. So, what can the 
Scrum master do in practice? 


E Promote Scrum practices across the product owner, development team, and those who interact 
with the Scrum master. 


m Assist the Scrum team by removing impediments and serving the team so the team can focus on 
delivering the Sprint goal. 
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Protect the team from outside interruptions (business) and distractions from inside the team. 
Coach the product owner in their vital role of supplying the prioritised list of stories from the business. 


Ensure team members don’t overcommit. Overtime is not part of the Scrum brief and the sprint. 
velocity informs the capability of the development team. 


Assist the team to achieve the sprint goal—serving the team by ensuring it has the necessary 
environment, tools and systems. 


Use insight and experience to ensure potential future issues are avoided, or at least minimised. 
Promote a positive culture during tough times, which is commensurate with the good times. 


Listen, observe and seek ‘inner direction’ when coaching the team to work in an optimal way. 


Although the servant leader qualities have been applied to the Scrum master’s role, the principles 


are equally as relevant for other styles of leadership—for example, for a traditional project manager: 


Listen as well as direct, remembering that communication is a two-way interaction. 


Take an interest in the people who make up the project team; avoid treating them as disposable 
resources. 


Employ the power of persuasion to keep the team productive and the sponsor (and other 
stakeholders) committed. 


Apply the trust equation (e.g. see http://trustedadvisor.com/whytrust-matters/understanding- 
trust/understandingthetrust-equation) and actively reduce any self-interested approach. 


Recognise the contributions of the project team: say ‘thank you’ and continue the positive 
motivation of the team. 


Interest is currently building in applying the subtleties of servant leadership not only within Scrum 


projects, but also in traditional project managerled multi-generational, multi-cultural, multicountry 
teams. There is no better time to be reading about the servant leadership approach than now and to 


consider implementing it—one step at a time, of course. 


The chapter has considered a number of ‘softer’ topics in relation to the project manager including: 


A cross-section of skills: These are the skills that a modern project manager must bring to the table to be considered well- 
rounded and capable of working in a business environment. Numerous skills have been considered under the PM's ‘talent 
triangle’ elements: technical project management, leadership, and strategic and business management. 

The ethical project manager. In today’s fast-paced, high-pressure environments, a project manager must remain 
ethical and moral in all their dealings, no matter how pressured they may be. Professional project management 
organisations require member project managers to demonstrate ethical behaviour and strong personal integrity. 
Trust and the project manager. ‘Trust withers through neglect. This is particularly true under conditions of rapid 
change and uncertainty that naturally engender doubt, suspicion, and even momentary bouts of paranoia. Project 
managers must maintain frequent contact with key stakeholders to keep abreast of developments, assuage 
concerns, engage in reality testing, and focus attention on the project. Frequent face-to-face interactions reaffirm 
mutual respect and trust in each other. 


This chapter also unpacked the stages of sourcing, developing, managing and disbanding project teams. Discussions 
encompassed: 


Selecting the best project sponsor for the project (and not basing selection on the politics of the business) and where 
the project manager has the trust and openness of the business to question any pre-allocated project sponsors. 
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m Recruiting the project manager and the project team: what to look for, including current industry demands of an 
organisational cultural fit; strong communication skills; flexibility; and multi-skilled, experienced employees. 

m Developing the project team, including the consideration of roles and responsibilities and the use of the RASCI Matrix 
to resolve conflict around role and responsibility assignment. 

m The Tuckman (and Jensen) team development model: how the project manager should be able to identify which ‘stage’ 
the team is at within this model and how they can resolve and move forward from issues with the team. 

m How maintaining a team performance and reward system is important to a project that delivers consistently. The 
project manager must build considerations into all aspects of the project, from budgets to schedules, to ensure time 
is allowed for positive team building. 

m Disbanding a team. When a team disbands, individual and team considerations need to be managed by the project 


manager. These should not be overlooked. Tuckman and Jensen's ‘Adjourning’ stage within their team development 
model reflects this stage of the project. 


The final section of the chapter reviewed the ‘servant leadership’ approach to the management of a team. Although 
Primarily applied to Scrum (Agile and their variants) approaches to project management, there is actually a lot that a 
modern project manager can learn from servant leadership and can apply in a traditional project environment. 

Project managers often work under less than ideal conditions to develop a cohesive team that is committed to working 
together and completing the project to the best of their abilities. They have to recruit personnel from other departments 
and manage this temporary involvement of team members. They have to bring strangers together and quickly establish a 
set of operational procedures that unite their efforts and contributions. They have to be skilled at managing meetings, so 
meetings do not become a burden but rather a vehicle for progress. Project managers need to forge a team identity and a 
shared vision that commands the attention and allegiance of participants. They need to use group incentives to encourage 
teamwork and identify when it is appropriate to recognise individuals for special acknowledgment. Project managers have 
to encourage functional conflict that contributes to superior solutions, while being on guard against dysfunctional conflict 
that can break a team apart. 
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See also Table 14.3. 


brainstorming management by wandering around trust (building trust) 
change management (MBWA) trust equation 
consensus nominal group technique (NGT) virtual project team 
dysfunctional conflict Positive synergy vision 

emotional intelligence (EQ) root cause walk the talk (WTT) 
functional conflict social network building 

kick-off meeting team-building 

majority versus consensus team charter 


decision-making team rituals 
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Review questions 
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hat are the elements of an effective project vision? Why are they important? 

hy should a project manager emphasise group rewards over individual rewards? 

hat is the difference between functional and dysfunctional conflict on a project? 

hen would it be appropriate to hold a formal team-building session on a project? 

hat are the unique challenges to managing a virtual project team? 

here do you normally sit on the leadership style continuum? 

at is the difference between leading and managing a project? 

hy is it important to build a relationship before you need it? 

hy is it critical to keep the project sponsor informed? 

hy is trust a function of both character and competence? 

hich of the traits/skills associated with being an effective project manager is the most important? The least important? 
hy? 

hat is ‘servant leadership’? 

at should you consider when disbanding a project team or releasing an individual project member? 
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hat is the difference between ‘consensus’ and ‘majority’ decision-making? How might each type of decision-making 
potentially affect project image? 


= 


IS 


w 


> 


p 


a 
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Define 12 questions that you could use at an interview for a project manager that would test their (your!) soft skills and 

leadership ability. 

Review the trust equation video (http://trustedadvisor.com/why-trust-matters/understandingtrust/understandingthe- 

trust-equation) and (using a scale of 1 = high, 10 = low) assess where you would place yourself and at least three other 

(de-identified) stakeholders you may have interacted with recently. What did you find? 

The following activities are to be based on a recently completed group project you have been involved in. This project 

may have been a student project, a work project or an extracurricular project. 

(a) Analyse how effectively the group managed meetings. What did the group do well? What did the group not do 
well? If the group were formed again, what specific recommendations would you make about how the group should 
manage meetings? 

The following activities are based on a current or recently completed group project that you have been involved in. This 

project may be a student project, a work project or an extracurricular project. 

(a) How strong is the team identity on this project and why? 

(b) What could participants do to strengthen team identity? 

(c) What kind of informal activities could be used to rejuvenate the team? Why would these activities work? 

Access the Project Management Institute website and review the standards contained in the ethics section. How useful 

is the information for helping someone decide what behaviour is appropriate and inappropriate? 

You are organising a concert for refugees in your home town that will feature local heavy metal rock groups and guest 

speakers. Draw a dependency map identifying the major groups of people that are likely to affect the success of this 

project. Who do you think will be most cooperative? Who do you think will be the least cooperative? Why? 

Identify an important relationship (co-worker, boss, friend) in which you are having trouble gaining cooperation. Assess 

this relationship in terms of the influence currency model. What kinds of influence currency have you been exchanging 

in this relationship? Is the ‘bank account’ for this relationship in the ‘red’ or the ‘black’? What kinds of influence would be 
appropriate for building a stronger relationship with that person? 


Additional case studies and appendices relevant to this chapter are available online. 
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PROJECT STAKEHOLDER 
MANAGEMENT 





Learning elements 


Understand the overall process of stakeholder management, including stakeholder 
identification, stakeholder analysis and stakeholder engagement. 


Be able to apply the basic concepts of stakeholder co-creation, to engagements 
with stakeholders. 


Be able to apply various stakeholder management tools and understand some of 
the complexities in the process of stakeholder management. 


Understand the links between stakeholder management, communications, and 
organisational change management (OCM). 


In this chapter 


15.1 Introduction 

15.2 Stakeholder co-creation 

15.3 Identifying stakeholders 

15.4 Analysing stakeholders 

15.5 Managing stakeholders 

15.6 Managing the impact of change on stakeholders 
15.7 Scrum/Agile considerations 


Summary 
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15.1 INTRODUCTION 


Over-eager project managers sometimes try to push their own agenda onto others, thinking this will 
spur on successful completion of a project. However, what they soon find out is that a project’s success 
depends on the cooperation of a wide range of individuals, many of whom do not directly report to the 
project manager. For example, during the course of a systems integration project, a project manager is 
surprised by how much time she is spending negotiating and working with vendors, consultants, technical 
specialists and other functional managers. Instead of working with the project team and stakeholders 
to complete the project, she finds herself being constantly pulled by the demands of different groups 
of people who are not directly involved in the project, but who nonetheless have a vested interest in its 
outcome. As a result, she starts to work longer hours to try to disentangle the situation, but this only leads 
her further towards the shadowy path of burnout and project disbandment by stakeholders. 

This chapter will review the process of stakeholder identification, stakeholder analysis and the 
building of lasting stakeholder strategies (collectively referred to as stakeholder management). 

First, the concept of stakeholder co-creation is discussed, as this influences all steps of the 
process—seeking to truly understand and build value for the project outcomes, the stakeholders and 
the project team. 


15.2 STAKEHOLDER CO-CREATION 


Co-creation (sometimes referred to as ‘sustainable project management’, ‘connected enterprise’ or value 
creation) is an emerging trend in stakeholder engagement. In summary, stakeholder co-creation is a 
form of cooperation in which all participants (stakeholders) influence the process and the result. This 
topic is introduced here, before the process of stakeholder engagement is discussed, so that readers can 
familiarise themselves with this concept and thus can layer it onto discussions as the chapter progresses. 

In practical terms, stakeholder co-creation is the close, trusted, positive, open-minded, supportive 
(with synergy), collaborative engagement of stakeholders to create project outcomes (outputs and 
benefits) that really add value to recipients (customers and society). For example, if a project manager 
was working on plans for the development of a new lowrise block of 20 apartments on the fringe of 
a suburban neighbourhood, they would need to engage in open dialogue with a range of stakeholders 
(i.e. neighbourhood citizens, the local council, local environment groups, potential customers for the 
apartments) to create value for all, within a cooperative environment. On paper, this may sound easy, 
but in practice, the project manager will need to create the environment for this to take place in a 
trusted manner. Complexities and dynamics have to be understood at a deeper level, ‘common ground’ 
has to be found at all stages of engagement, and conflict and negotiation has to be managed to reach 
outcomes (sometimes involving a compromise) to suit all (we're going beyond ‘win-win’ here!) Often, 
innovative (future-orientated) solutions will need to be found for complex problems. Stakeholder co- 
creation brings other techniques into the project environment such as: 


= Action learning: The project manager and project team takes a ‘do’, ‘reflect’, and ‘learn’ 
approach, in order to inform the current cycle of engagement and be able to adjust the next cycle 
of engagement (see Figure 15.1). 


= Organisational development (OD) for internally focused projects: This is where a planned 
and systematic approach towards enabling sustained organisational performance, through the 
involvement of the organisation’s people is taken (see Figure 15.2). 


m Sustainable development: Where the aims are to deliver products and services that are 
sustainable in the real world (see Figure 15.3)—considerate of not just the ‘green’ aspects of 
sustainability, but a more holistic approach to sustaining outcomes for the long term in society. 


Em Organisational change management (OCM): OCM focuses on the organisational change impact 
to the organisation, departments, teams and individual employees, and their ability to carry out. 
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Assessment of the 
challenge (area under § 
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problem/goal 


Dialogue with the 
group, listening, 
challenging perceptions, 
questioning 


Integrate the learning 
and actions into the 
business 


Studying the outcomes, 
what went well, what 
didn’t go so well, what 
could be done better 
next cycle 


Reflection, creation of 
new ideas, exploring 
new perspectives, 
actions and preparation | 


Making the change, 
applying the actions 
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Anticipate the need 
for change 


Implement, monitor and Invest in twoway relationships: 
stabilise the improvement project to client and 
in the business client to project 


Plans, actions and strategies Diagnose the problem, 
to improve the root causes what’s the root causes? 





Source: © 2018 Dr Neil Pearson 


their functions successfully during project. execution and also after implementation in ‘business as 
usual’. See Figure 15.4 for the steps that are promoted by a popular resource on this subject. 


These subjects are disciplines in their own right, but even having a brief understanding hopefully 
influences the project manager's thought. patterns and actions regarding how stakeholders should be 
engaged with. At the crux of stakeholder cocreation is the concept. of understanding, creating and 
then delivering value to the project stakeholders. Value involves ultimately understanding what each 
stakeholder wants—which, of course, will be different for each, according to their own unique perspective. 
For example, in the apartment build, the customer of the apartment might seek a value proposition of 
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Figure 15.4 Organisation change management 





Source: The Change Leader's Roadmap, Dr Linda Ackerman Anderson & Dr Dean Anderson, Pfeiffer, 2010 © 2018 Being First 


‘high-end, accessible, with full amenities’; while the neighbourhood citizen might seek ‘low environmental 
impact, fits with the landscape of the community and is suitably landscaped to minimise visual impact’. 
Understanding the differing stakeholders’ value propositions and their complexities and interplays helps 
the project manager to unpack any conflicts. This insight is key to working towards creating value in 
stakeholder co-creation. In the past, project managers may have casually sought to understand the ‘What’s 
in it for me?’ (WIIFM) factor. Co-creation takes this further by understanding the true value proposition 
for each impacted stakeholder, working towards maximising value to all impacted stakeholders. 
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When developing the concept of stakeholder co-creation, and identifying what this means to 
the respective stakeholders, the project manager could use diagrams that. combine elements of the 
stakeholder network diagram (refer to Figure 15.6) and rich pictures (introduced in Chapter 7; see 
Figure 7.3) to create a pictorial understanding of the co-creation ecosystem. 


E The stakeholder network diagram indicates stakeholders, relationships, networks and interactions. 


E The rich picture diagram indicates activities, artefacts and, most important, emotions—of what is 
being ‘felt’. 


When the two are combined and applied to groups, such as crowds of people, movements of people, 
communities of people, clubs of experts and coalitions of parties, the project manager can start to understand 
the true value of what stakeholders are seeking and how the resulting ecosystem feeds and reacts to those 
within it. Refer to Figure 15.5 for an example of the result of carrying out a co-creation workshop. 

The reader is encouraged to review further resources on stakeholder co-creation. 


15.3 IDENTIFYING STAKEHOLDERS 


Ultimate success is not determined by whether a project is completed on time, within budget, or according 
to specifications, but. rather by whether the customer is satisfied with what has been accomplished. 
Customer satisfaction is the bottom line. Bad news travels faster and farther than good news. A happy 
customer is likely to share their satisfaction about a particular product or service with another person. An 
unhappy customer, however, is statistically likely to share their discontent with up to eight other people! 
Project managers need to cultivate positive working relations with clients to preserve their reputations. 
When new project managers ge find time to work directly on the project, they often adopt a hands- 
on approach towards managing the project. They choose this style, not because they are power-hungry 
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egomaniacs, but because they are eager to achieve results! They often quickly become frustrated by 
how slowly things operate, by the number of people who may have to be brought. on board, and the 
difficulty of gaining some people’s cooperation. Unfortunately, as this frustration builds, the natural 
temptation is to exert more and more pressure and to get more heavily involved in the project. When 
this happens, the project manager tends to quickly earn the reputation of being a ‘micro manager’ and 
begins to lose sight of the real role they play in guiding a project. 

Some new managers never break out of this paradigm. Others soon realise that autherity dees 
net equal influence and that being an effective project manager involves managing a much more 
complex and expansive set of interfaces than they had previously anticipated. They encounter a web 
of relationships that require a much broader spectrum of influence than they had initially felt was 
either necessary or even possible. 

When thinking of stakeholders in a project environment, it is useful to once again think of æ cycle, 
as illustrated in Figure 15.6. Stakeholder engagement is strongly tied to project communications (see 
Chapter 16)—we communicate with stakeholders! 

Consider for example, a significantly sized project (such as creating a new product or installing 
a new information system), which will, most likely, encompass working with a number of different 
groups of stakeholders. There will be a core group of specialists assigned to complete the project, and 
this group is likely to be supplemented at different times by professionals who will work on specific 
segments of the project. There will also be groups of people (within the performing organisation) 
who will either directly, or indirectly, become involved with the project. This will typically include top 
management, to whom the project manager will be accountable. There will also be other managers 
who will provide resources and/or who may be responsible for specific segments of the project, as 
well as for administrative support services (such as human resources and finance). 

Depending on the nature of the project, there may also be a number of different groups outside 
the organisation that will influence the success of the project; the most important of these of course 
will be the customer; for whom the project is being designed. Mapping stakeholders and their various 
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stakeholder relationships is extremely useful. Brainstorming the identification of stakeholders and 
understanding the relationships between stakeholders is critical not only at the Initiating stage of 
the a project, but also at the start of each stage of the project life cycle, and sometimes within each 
stage. Figures 15.7A, 15.7B, 15.7C and 15.7D represent a number of different approaches towards 
‘brainstorming’ stakeholder identification. Each of these approaches could be accomplished by 
carrying out a Post-It® note group brainstorming session. Remember, the more inclusive the project 
manager can make such activities, the better the chance of identifying all stakeholders, and the 
greater the buyin from the project team and the stakeholders. 

Each stakeholder group will bring different expertise, perspectives, priorities and agendas to the project. 
Stakeholders are people and organisations who are actively involved in the project, or whose interests 
may be positively or negatively impacted by the project. The sheer breadth and complexity of stakeholder 


Figure 15.7A Identifying stakeholders, primary or secondary approach 
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Figure 415.71 e g stakeholders, internal or external approach 
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Figure 15.7C Identifying stakeholders, primary or secondary approach 





Primary/Secondary analysis 





m Primary — Key project stakeholders 
m Secondary — Less critical project stakeholders 
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Figure 15.7D Identifying stakeholders, stakeholder wheel approach 
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relationships is what distinguishes project management from ‘regular’ management. To be effective, a 
project manager must identify the right stakeholders to the project, understand how these stakeholders 
can affect the project, and develop methods for managing them. Typical stakeholder groups include: 


m Customers define the scope of a project, and ultimately the project's success depends on their 
satisfaction. Project managers need to be responsive to any changing needs and requirements the 
customer has, and must ensure their expectations are met. 


E The project team manages and completes project work. Most participants will want to do a good 
job, but they will also be concerned with their other obligations and how their involvement in the 
project will contribute to their own personal goals and aspirations. 
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Figure 15.7E Ident: 
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E Project managers naturally compete with each other for resources and for the support of top 
management. At the same time, they often have to share resources and exchange information. 


E Administrative support grou ps, such as human resources, information system operators, 
purchasing agents and maintenance staff, provide valuable support services. At the same time, 
they impose constraints and requirements on the project, such as requiring expenditure to be 
documented and the delivery of information to be timely and accurate. 


E Functional managers (depending on how the project is organised) can play a minor or major role 
in the project's success. In matrix arrangements, they may be responsible for assigning project 
personnel, resolving technical dilemmas, and overseeing the completion of significant segments 
of project work. Even in dedicated project teams, the technical input from functional managers 
may be useful, and their acceptance of completed project work may be critical. Functional 
managers usually want to cooperate up to a point, but only up to a certain point as they will also 
be concerned with preserving their status within the organisation and minimising the disruptions 
the project may have on their own da yto-day operations. 


E Top management approves funding of the project and establishes priorities within the 
organisation. Top management defines ‘success’ and adjudicates rewards for accomplishments. 
Significant adjustments in budget, scope and schedule typically need top management’s approval. 
Top management will have a natural, vested interest in the success of the project, but at the same 
time has to be responsive to what is best for the entire organisation. 


Æ Preject sponsors champion the project and use their influence to gain approval of the project. Their 
reputation is tied to the success of the project, and they need to be kept informed of any major 
developments. They defend the project when it comes under attack and are a key project ally. 


E Contractors (in some cases) may conduct all of the actual work, with the project team 
coordinating their contributions. In other cases, they are responsible for ancillary segments of 
the project scope. Poor work outcomes and schedule slips can affect the work of the core project 
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team. While contractors’ reputations depend on them doing good work, they must also balance 
their contributions with their own profit margins and their commitments to other clients. 


Em Government agencies typically place constraints on project work. Permits need to be secured. 
Construction work has to be built to code. New drugs have to pass a rigorous battery of tests. 
Other products have to meet safety standards (e.g. workplace health and safety standards). 


Em Other organisations (depending on the nature of the project) may directly or indirectly affect the 
project. For example, suppliers provide necessary resources for completion of the project work, 
and delays, shortages and poor quality can bring a project to a standstill. Public interest groups 
may apply pressure on government agencies. Customers often hire consultants and auditors to 
protect their interests on a project. 


Stakeholders are often grouped into primary stakeholders, who are the individuals and groups most 
affected by the outcomes of the project; and secondary stakeholders, who are the individuals or groups not 
directly affected by the outcome of the project, but. who still have an interest in it. Secondary stakeholders 
often help by providing assistance to the primary stakeholders. These relationships are interdependent, 
in that a project manager's ability to work effectively with one group will affect their ability to manage 
other groups. For example, functional managers are likely to be less cooperative if they perceive that top 
management's commitment to the project is waning. Conversely, the project manager's ability to buffer the 
team from excessive interference from a client is likely to increase their standing with the project team. 


15.3.1 The Stakeholder Register 


Identifying stakeholders, according to the manner used in Figures 15.7A, B, C and D, forms the start of 
the process of actively identifying a project’s stakeholders. As part of this process, the project manager 
will develop what is often referred to as the Stakeholder Register. This document is used by the project 
manager to maintain (and regularly review) details of stakeholders within the project. Information 
collected at the stakehelder identification stage could include (among a whole host of other information): 


The stakeholder’s name. 


The stakeholder’s functional role (e.g. the position the stakeholder has in the organisation's structure). 


The stakeholder’s contact details and (optionally) the contact details of a secondary stakeholder 
who can be contacted when the primary stakeholder is unavailable. (In preference, the secondary 
stakeholder should have the same decision-making accountability as the primary stakeholder). 


Information about whether the stakeholder is ‘internal’ or ‘external’ to the organisation. 


Details of ‘what the stakeholder wants from the project’ (i.e. capturing the agreed expectations of 
what they will receive from the project). (This could range from, for example, receiving project 
updates through to outcomerelated activities.) 


m Details of ‘what the project wants from the stakeholder’ including agreement on their decision 
making ability, and any information and/or resources they are to provide to the project. 


@ Current perceptions and knowledge: this forms the start of change management activities for 
the project—by capturing current perceptions and knowledge, the project manager knows what 
perception the stakeholder has of the ‘asis’ state. 


E Desired perceptions and knowledge: This is the project’s assessment of where the project has to 
move the stakeholder—from the ‘asis’ state to the project’s vision or ‘tobe’ state. 


m Details of any stakeholder personal preferences, ‘pet hates’ (e.g. about when/when not to contact 
them), any ‘points of passion’ (positive or negative), how they wish to be addressed, etc. Having 
this kind of information to hand can help navigate around particularly prickly stakeholders. 


@ Organisational currencies. These are discussed in detail later. 


Source: ® 2018 Dr Neil Pearson 
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SNAPSHOT FROM PRACTICE The project manager as conductor 





Metaphors convey meaning beyond words. For example, 
a meeting can be described as being ‘difficult’ or ‘like 
wading through molasses’. A popular metaphor for the 
role of a project manager is that of a conductor The 
conductor of an orchestra integrates the divergent sounds 
of different instruments to perform a given composition 
and make beautiful music. Similarly, the project manager 
integrates the talents and contributions of different 
specialists to complete the project. Both have to be good 
at understanding how the different players contribute to 
the performance of the whole. Both are almost entirely 
dependent upon the expertise and know-how of the 
players. The conductor does not have command of all 
the musical instruments. Likewise, the project manager 
usually possesses only a small proportion of the technical 
knowledge needed to make decisions. As such, the 


conductor and project manager both facilitate the 
performance of others rather than actually perform. 

Conductors use their arms, baton and other non- 
verbal gestures to influence the pace, intensity and 
involvement of different musicians. Likewise, project 
managers orchestrate the completion of the project 
by managing the involvement and attention of project 
members. Project managers balance time and process, 
and induce participants to make the right decisions 
at the right time, just as the conductor induces the 
wind instruments to perform at the right moment in a 
movement. Each controls the rhythm and intensity of work 
by managing the tempo and involvement of the players. 
Finally, each has a vision that transcends the music score 
or project plan and to be successful, they must both earn 
the confidence, respect and trust of their players. 


The preject management erganisatienal structure being used will influence the number and degree 
ef external dependencies that will need te be managed. @ne advantage ef creating a dedicated pre ject 
team is that it reduces dependencies (especially within the erganisatien) because mest ef the reseurces 
are assigned te the preject. Cenversely, a functienal matrix structure increases dependencies, with 
the result that the preject manager is much mere reliant upen functienal celleagues fer werk and 
staff; see Chapter 5. 

The eldfashiened appreach fer managing prejects emphasised directing and centrelling 
suberdinates. The centemperary perspective emphasises engaging with preject stakehelders and 
anticipating change. Preject managers need te be able te assuage (relieve) custemer cencerns, sustain 
suppert fer the preject at higher levels ef the erganisatien, and be able te quickly identify preblems 
that threaten preject werk, while at the same time defending the integrity ef the preject and the 
interests ef the preject participants. Within this web ef relatienships, the preject manager must find 
eut what needs te be dene te achieve the geals ef the preject, and build a ceeperative netwerk fer 
accemplishing this (stakehelder ce-creatien). Preject managers undertake and achieve this witheut 
expecting er demanding ceeperatien. This necessitates using seund cemmunicatien skills, leveraging 
pelitical capital, and tapping inte a bread influence base. (See Snapshet frem Practice: The preject 
manager as cenducter, fer mere abeut. what characterises a preject manager.) 


15.4 ANALYSING STAKEHOLDERS 


15.4.1 Stakeholder currencies 


To successfully manage a project, a manager must adroitly build a cooperative network among 
divergent allies. Networks are mutually beneficial alliances that are generally governed by the law 
of reciprocity. The basic principle is that ‘one good deed deserves another’. The primary way to 
gain cooperation is to provide resources and services for others in exchange for future resources and 
services. This is the ageold maxim ‘quid pro quo’ (something for something) or, in today’s vernacular, 
‘You scratch my back, I'll scratch yours’. 

Cohen & Bradford (2005) describe the exchange perspectives of ‘influence’ as currencies. If you 
want to do business in a given country, you have to be prepared to use the appropriate ‘currency’ and 
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the exchange rates can change over time, as conditions change. In the same way, what is valued by a 
marketing manager may be different from what is valued by a veteran project engineer, and a project 
manager therefore may need to use a different influence currency to obtain the cooperation of each 
individual. Although this analogy is simplified, the key premise holds true—in the long run, ‘debit’ 
and ‘credit’ accounts must be balanced for cooperative relationships to work. (The online resource, 
Stakeholder Currencies, explains Cohen and Bradford's model in detail.) 

The bottom line is that a project manager will be influential only insofar as they can offer something 
that others value. Furthermore, given the diverse cast of people a project manager depends upon, it 
will be important that they both acquire and exercise a variety of different ‘influence currencies’. The 
ability to do this will be constrained in part by the nature of the project and how it is organised. For 
example, a project manager who is in charge of a dedicated team has considerably more to offer team 
members than a manager who is given the responsibility of coordinating the activities of different 
professionals across different departments and organisations. In the latter case, the project manager 
will probably have to rely more heavily on personal and relational bases of influence for gaining the 
cooperation of others. 


15.4.2 Stakeholder analysis using various grids 


Analysing the state of stakeholders will be an ongoing activity for the project manager. The 
management of stakeholders is truly a cross-life-cycle effort: different stakeholders will require 
different levels of attention during the different stages of the project life cycle. For example, the 
project manager may have a lot of contact with the project sponsor or senior business users during 
the Initiating stage of a project, but during the Planning stage of the project, the management of 
stakeholders may shift to the ‘end users’ on the ground (who are going to be the recipients of the 
outputs and outcomes of the project). During this stage, the sponsor may require exception reports 
on progress from the project manager. Being able to analyse stakeholders and design strategies to 
manage them is critical to project success. 


POWER/INTEREST GRID 


The Power/Interest Grid (see Figure 15.8) is often used for assessing and managing a stakeholder’s 
‘power and interest’ in a project through the project life cycle. 


Figure 15.8 T 
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By mapping ‘power and interest’ (on a relative scale of ‘high to low’) the project team can review 
the status of each stakeholder and apply appropriate strategies for managing stakeholders. The 
intersections on the Power/Interest Grid are frequently annotated with: 


E Manage clesely (high pewer/high interest): These stakeholders are actively managed. They not 
only have a high interest in the project, but also have the pewer te influence (in either a positive 
or negative manner). Examples of these types of stakeholders include the project sponsor, key 
users and funding providers. 


E Keep satisfied (high pewerNew interest). These stakeholders need to be kept satisfied. This 
type of stakeholder could for example, be an external government department that doesn’t have 
a direct interest in the project, but could influence its outcome. For example, when managing a 
(non-government) project that is subject to government legislation, the government would likely 
have little to no direct interest in the project itself. However, should a government change in 
policy occur, this ceuld potentially have major implications for the project. 


E Keep infermed (lew pewer/high interest). Here, stakeholders ceuld hold important influence, 
despite not being ‘high’ on the ‘power dimension’. In this situation, they must be kept informed 
about relevant information and decisions. Examples might be technical experts, executive 
assistants and the general user base affected by the project. 


E Meniter (lew pewerlew interest): These are the minimum maintenance stakeholders. Keep 
them informed and monitor for any changes in their power and/or interest. Send them a weekly 
newsletter or provide an intranet page for them to review. 


Knowing where your stakeholders are positioned on the Power/Interest Grid and understanding 
the dependencies (relationships) that exist between these stakeholders can involve a bit of detective 
work. The project manager will be on a journey of discovery to work out how this network is 
interlinked and intertwined! 


STAKEHOLDER CONTINUUM ANALYSIS 


Another technique that can be used is to place stakeholders en æ centinuum. This continuum will 
resemble something akin to the continuum indicated in Figure 15.8, where a stakeholder is positioned 
ona scalefrom project ‘Opposer’ through to project ‘Promoter’. 

PMBOK (PMI, 2017) draws on the 
concept of a stakeholder continuum with the 
introduction of the Stakeholder Engagement 
Grid (illustrated in Table 15.1). This maps Gece .. (we ëa 
the current. (‘C’) and desired (‘D’) level of sitter 
engagement by the stakeholder. 


Figure 15.9 ontinuum 





Table 15. Stakeholder Engagement Grid 
Stakeholder |Role Unaware Supportive Leading 


John Smith Project Sponsor (a D 
Key 
Unaware: Unaware of the project and any potential impacts 
Resistant: Aware of the pr@ject and its potential impacts and is resistant to change. 
Neutral: Aware of the project yet neither supportive nor resistant. 
Supportive: Aware of the project and potential impacts and supportive of the change. 
Leading: Aware of the preject and potential impacts and actively engaged in the success of the preject. 
And: Current Engagement = C 
Desired Engagement = D 
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CONTRIBUTION/COMMITMENT GRID 


The Contribution/Commitment Grid, as illustrated in Figure 15.10, provides a more detailed insight. 
into the stakeholder’s involvement in the project. The degree to which a stakeholder is required to 


contribute to a project to ensure its success depends on a number of factors including: 


The stakeholder’s position and authority within the organisation. 


The degree to which the project is reliant upon the particular stakeholder to provide a product or 
service te the project. 


The level of social influence the individual has and the degree to which the individual is familiar 
with specific aspects of the business. 


Each of these factors can be analysed in more detail during the stakehelder analysis. The outcome 


is summarised in a centributien index, with the following values: 


Critical: The stakeholder has the power to make the project succeed, or to prevent it from 
succeeding altogether. 


Desirable: The project can be completed even without an active contribution from the 
stakeholder, but this would have a serious impact on the quality, elapsed time and cost of 
execution. The stakeholder is able to act as an advocate for the project, to peers. 


Nen-essential: Although the stakeholder can contribute to the project, their contribution is either 
not essential or can be more easily obtained from other stakeholders. Note: An individual with a 
contribution index below ‘nonessential’ may not be a stakeholder of the project. 


Each stakeholder will display a different level of commitment to the project throughout the life of 


the project. 


Cemmitted (wants to make the project happen): The stakeholder has made a commitment to 
contribute to the project (preferably in writing) and is available to do so. Their commitment may 
be documented in the form of an agreed plan, describing what will be provided and by when, or in 
other forms of written communication (e.g. email, memo, letter, contract, statement of intent). 


Figure 15.10 
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E Supportive (wants to be involved in making the project happen): The stakeholder is well informed 
and sees value in what is being produced from the project. The stakeholder understands their 
contribution and is willing to provide it, although no formal commitment has been entered into. 


m Neutral (will let the project happen, shows indifference). The stakeholder may or may not be 
informed about the project and, while they do not disagree, they are not actively involved in any 
capacity, or may be indifferent about the project’s objectives and outcomes. 


E Disagrees (will try to stop the project from happening): The stakeholder may or may not be 
informed, but does not see value in the project and the work being performed. They would rather 
not be involved in the project and in fact would prefer the work not to be carried out at all. 


As a result of this analysis the project manager could add the fellowing items to the Stakeholder 
Register: 


E Current commitment level: For example, a project manager may update the Stakeholder Register 
following a meeting, by placing Brad's details in the critical/neutral segment of the grid. 


E Desired commitment level—After discussions with the project team, the project manager wishes 
to move Brad into the critical/committed segment of the grid. 


@ Action steps—Much like the ‘asis’ and ‘to-be’ states described earlier in this chapter, these are the 
steps that the project team needs to take with the stakeholder in order to move the stakeholder’s 
position from the current commitment level to the desired commitment level. 


Note: Figure 15.10 shows the positions of two stakeholders. The red line indicates a stakeholder 
who considers themselves to have more importance than the project deems them necessary to have, 
so actions are about downwardly managing this stakeholder. The blue line indicates the opposite: a 
stakeholder is assessed as being of lesser importance than the project requires so actions are about 
upwardly managing this stakeholder. In both cases the stakeholder actions (or strategies) will be 
determined to move the stakeholder into the best position for the project's success and these actions 
will be allocated to project team members for follow-up. 


15.5 MANAGING STAKEHOLDERS 


No matter what tools are used to identify, and then subsequently analyse, the project’s 
stakeholders, the project manager must be cognisant of the fact that perceptions about 
stakeholders can change. Some of this change will occur within the project while other 
changes may occur that are beyond the understanding of the project manager. There are many 
complexities involved with managing stakeholders and the tools mentioned in this chapter so far 
have all been around stakeholder identification and analysis. In the Cranfield University School 
of Management report Stakeholder Engagement: A Road Map to Meaningful Engagement, Neil 
Jeffery (2009) provides a useful summary of some of the complexities involved in managing 
stakeholders. Included in his list are: 


= Trust: Trust must be established (often quickly) to gain a healthy stakeholder relationship. It is 
often the factor that underpins the relationship before other aspects can be truly developed. The 
building of trust is a fundamental prerequisite to meaningful engagement, as is a focused effort 
to deepen the level of trust during engagement. One of the greatest steps in building trust is to 
understand the motivation of your stakeholders. 
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m Motivation: The motivation of stakeholders to enter into dialogue may be different, particularly 
when the two parties are organisations of ‘radically differing ethos, values and culture’ (e.g. a 
commercial company providing services to a project being run by a notfor-profit organisation). 
Insuch cases, it is important for each party in the engagement process to recognise, analyse and 
understand the underlying motivation of the other, as a critical step in building and strengthening 
the relationship. 


E Embeddedness of stakeholder thinking: The degree to which an organisation can achieve meaningful 
stakeholder engagement depends on how embedded concepts are across the organisation. 


E The importance of accurate representation: The importance of achieving accurate representation 
of all your stakeholders and stakeholder types. For example, if you are engaging with a 
population mixed across race, religion, gender, region, age, class, sexual orientation and 
education (or even time-poor stakeholders), it is important that you elicit views that represent 
this diversity as well as consider effective ways to engage with a cross-section of the stakeholder 


population, which will differ across groups. 


E Tone from the top: Appropriate leadership is fundamental in the building of meaningful 


engagement by an organisation, exemplified by the role of the CEO in convincing employees, 
investors and clients that engagement with a broader set of stakeholders is worthwhile. Even if 
an organisation has the appropriate capabilities and organisational culture to allow meaningful 


engagement to develop, without the approval and active leadership (through both words and 
deeds) of its CEO, it is unlikely to be successful. 


E Organisational behaviour: Understanding an organisation and being able to successfully analyse 
the nature of its organisational behaviour and culture is key to forecasting how engagement with 


stakeholders will develop, what critical issues and challenges may arise and how meaningful 


relations may be achieved. Depending on its culture, the organisation may respond in a different 


way to stakeholders. 


E Non-preductive engagement behaviour: Sometimes nonproductive engagement can exist; this is 


when previous engagement has not produced a positive outcome and therefore has been ‘abandoned’ 


SNAPSHOT FROM PRACTICE Complex stakeholder management— 


a simple solution 





A large business change project had to establish a 
way of tracking stakeholder discussions across a multi- 
country project team. The project team, as a result of the 
stakeholder analysis, had decided to split the management 
of stakeholders across the project team. 

Freel managed three executives; Sarah managed 
another three; and the project manager, Louise, managed 
a further two. While managing these eight stakeholders, 
the project team adhered to their project rule that they 
woule only ever liaise with their nominated stakeholders 
and would never ‘cross-discuss’ project matters with 
other team members’ stakeholders. This made perfect 
sense from a stakeholder management perspective, in 
that trust, understanding and engagement were quickly 
established with the various executives. However, the 


project team ha@ to work out the technicalities for 
sharing stakeholder information with the rest of the 
team members and for allowing a platform for questions 
to be posted to a nominated project team member, 
ready for any upcoming meetings that project team 
member had. 

The solution for managing this level of complexity of 
stakeholder information came in the form of leveraging 
the functionality of a customer relationship management 
(CRM) software package. The project adopted Vtiger 
(https:/wwwtiger.com/crm/), a CRM clou@-basedl software 
solution, so all stakeholder information could be shared 
among the project team instantly, with notifications set to 
gain updates on stakeholders when entries were made 
in a stakeholder’s record. 
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by either or both parties. Several challenges can arise from this situation as a result of the engagement 
issue not being resolved: either it can reemerge later as a more difficult subject to address, or the 
abandonment of the issue in itself can further inflame already difficult stakeholder relations. 


Some of the complexities that can quickly develop when managing multiple, often seniorevel 
stakeholders, are illustrated in Snapshot from Practice: Complex stakeholder management—a simple 
solution. 

In Chapter 7 it was emphasised that ultimate success is not determined by whether the project 
was completed on time, within budget or according to performance specifications, but whether the 
custemer is satisfied with what has been accomplished. Customer satisfaction is the bottom line. 

‘Customer satisfaction’ is a complex phenomenon but one simple (and useful) way of viewing 
customer satisfaction is in terms of met expectations. According to the ‘met expectations model’, 
customer satisfaction is a function of the extent to which the perceived performance (or outcome) 
exceeds expectations. Mathematically, this relationship can be represented as the ratio between 
perceived perfermance and expected perfermance (see equation). When performance falls short of 
expectations (ratio <1), the customer is dissatisfied. If the performance matches expectations (ratio = 
1), the customer is satisfied. If the performance exceeds expectations (ratio >1), the customer is very 
satisfied, or even delighted. 


0.90 _ Perceived performance _ 1.10 
Dissatisfied  Expectedperformance Very satisfied 





High customer satisfaction is the goal of most projects. However, profitability is another major 
concern. For example, completing a construction project two weeks ahead of schedule may involve 
significant overtime expenses. Similarly, exceeding reliability requirements for a new electronic 
component may involve considerably more design and debugging effort. Under most circumstances, 
the most profitable arrangement occurs when the customer's expectations are only slightly exceeded. 
Retuming to the mathematical model: with all other things being equal, one should strive for a 
satisfaction ratio of 1.05, not 1.5! 

The met expectations model of customer satisfaction highlights the point that whether a client 
is dissatisfied or delighted with a project is net based on hard facts and objective data, but on 
‘perceptions’ and ‘expectations’. For example, a customer may be dissatisfied with a project that was 
completed ahead of schedule and under budget if they thought the work was of poor quality and that 
their fears and concerns were not adequately addressed. Conversely, a customer may be very satisfied 
with a project that was over budget and behind schedule if they felt the project team protected their 
interests and did the best job possible under adverse circumstances. 

Project managers must be skilled at managing customer expectations and perceptions. Too often 
they deal with these expectations after the fact when they try to alleviate a client’s dissatisfaction 
by carefully explaining why the project cost more or took longer than planned. A more proactive 
approach is to begin to shape expectations up-front and to accept that this is an ongoing process 
throughout the life of a project. Project managers need to direct their attention both to the customer’s 
base expectations (the standard by which perceived performance will be evaluated) and to the 
customer's perceptions of actual performance. The ultimate goal is to educate clients so they can 
make a valid judgement. as to preject perfermance. 

Managing customer expectations begins during the preliminary project approval stage 
of negotiations. It is important to avoid the temptation to oversell the virtues of a project to win 
approval, because this may create unrealistic expectations that may be too difficult, if not impossible, 
to achieve. At the same time, project proponents have been known to lower customer expectations 
by underselling projects. If the estimated completion time is 10 to 12 weeks, they will promise to have 
the project completed within 12 to 14 weeks, therefore increasing the chances of exceeding customer 
expectations by getting the project completed early. 
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15.6 MANAGING THE IMPACT OF CHANGE ON 
STAKEHOLDERS 


As well as managing dynamics around stakeholders who have an interest in the project, stakeholders 
who will be the recipients of the project's outcomes and outputs and who will be impacted by the 
project may also require considerable management. This is especially the case as the project moves 
through Planning into Executing. Although the project manager can identify, analyse and plan 
strategies and communications for managing these impacted stakeholders, the real skill comes from 
the application of organisational change management practices (a number of approaches are listed 
in the weblinks at the end of this chapter). 

The success of implementing an Enterprise Resource Planning (ERP) system for example, would 
depend upon its end users (across all departments in the organisation) having the awareness, desire, 
knowledge and ability to use the system. Another example could be the implementation of an improved 
process for triaging a hospital’s accident and emergency admissions, to ensure the hospital can meet 
its four-hour service level agreement (SLA): the administration staff, nurses and doctors (etc.) will 
all need to have the awareness, desire, knowledge and ability to make this process change a success. 

To frame this discussion, the authors have selected an organisational change management. 
approach—ADKAR®—that focuses on groups of stakeholders that are immediately impacted by 
change. Refer to Figure 15.11 for a brief overview of the approach, which is accompanied by an 
example of an employee's response to the introduction of a new policy pertaining toa local government. 
department's implementation of a lone worker GPS tracking device for social workers. 


Referring to Figure 15.11 (working across a row in the table): 


Figure 15141 An employee’s ADKAR to the introduction of a lone worker GPS tracker and alert service 




















Example. Staff meeting announcement telling 
employees they would be tracked during working 
hours for social work visits. 

The lone worker device would remove need to 
travel in pairs to at risk clients. 







Am I aware of 
the need for 
change? 


is your employee 
aware of the need 
for change? 








no awareness 
5 =total awareness 


















Example. No, Don't believe in being tracked. 












Does your employee Do I have the Big brother. Where does it stop? Doesn't help if you 
have the desire to desire to are attacked, as the chance of getting to and setting 1= no desire 
participate in the participate in €if the alert would be difficult. Removing a physical 5= strong desire 




































change? the change? pairperson to save a few bucks but putting 
individual personal risk up to a high level. 
a Do Ihave the Example. Only manufacturers instructions provided fesrolkenowledne 


No information on how to temporary disable. No 
information on what data is collected and how 
it will be used. 


knowledge to 
make the 
change? 


5=highly 
knowledgeable 


have the knowledge 
to make the change? 











Example, Switch device on and off but not use the 
device how | want. to fit in with proven suspicions 
that data is continually collected. 


Can your employee 
put their knowledge 
into practice? 


Can | put my 
knowledge into 
practice? 






1 = no ability 
5 = very able 


*@DIA@P Yale PUE 1YIL} Sd9 484JOM SU] 
JO UONINpo.AU! Bly 0} YYAAY S,ƏƏÁojdwə ue ‘jdu exg 





















Do you have Are 
Reinf t earem si reinforcements Example. No answers to questions raised at team 1 =is not helpful 
einforcemeni RES RORE, present that are and other meetings. 5= is very helpful 






employee from 


? 
reverting to ole habits? useful? 


Source: Adapted from ADKAR®: A Mede! for Change in Business. Gevernment ane! Our Cemmunity, Prosci Learning Centre Publications, Loveland, Colorado, 
2006, This figure © 2018 Dr, Neil Pearson (diagram with example) 
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The first arrow (in any row) indicates the ADKAR word. 
The second is a definition from an employer perspective. 


The third is a question an employee can rhetorically ask themselves. 


The fourth is an example of an employee's ADKAR to the introduction of lone worker GPS tracker 
and alert device 


The fifth is a score system for the employee to complete, based on their perceptions. 


The circle represents the score given. 


The project manager could collect these survey sheets and start to review the responses: taking the 
first row that scored 3 (or below), they would start out by trying to understand the root cause (the ‘why’) 
so they can address the concern. For example, in the first row, a score of 3 for ‘Awareness’ could trigger 
an exploration of the reasons and benefits for the change with the individual, both at an organisational 
level (in terms of budgets and resources) and an individual level (we do care about employee safety). The 
project manager would then move down to the next row scoring 3 or less: In this case, ‘Desire’ would be 
investigated with the employee to try and lower their ‘resisting forces’ and increase their ‘positive forces’. 
All the other ‘sub-3’ scores would be addressed. In doing so, the project manager (or allocated project 
team member) works at the ‘coal face’ with the people directly affected by the change. 

If these types of tools are applied during the project. Executing stage (prior to implementation) they 
have proven to bring about more successful change that is sustainable inthe longer term. Note: The authors 
encourage the reader to follow through on this topic by undertaking additional reading and professional 
development, as the topic of organisational change management is so important in project management. 

In addition to having access to various organisational change management approaches, the project 
manager should be aware of other supporting resources. For example, the authors have regularly used 
Fisher's personal transition curve to understand how individuals deal with change (see Figure 15.12). 


Figure 15412 Fist al transition curve 
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Source: Fisher J M 2000, ‘Creating the future?’, in Scheer J W (ed), The Person in Society: Challenges to a Constructivist Theory, Geissen, PsychosozialVerlag 
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Readers may like to take to a more indepth look at Fisher’s (2012) personal transition curve at. 


https://w ww. businessballs. comn/change-management/personal-change-stages-johnfisher-162/. 


Other simple tools can also be used to review the ‘asis’ and ‘tobe’ states, for example the McKinsey 


7-S (1982) framework as illustrated in Figure 15.18. 


The ‘hard’ elements include: 
Strategy: What has to be challenged strategically and changed in order for the ‘tobe’ to be made a 
reality. 


Structure: The physical organisational structure and reporting lines—what has to be changed in 
order for the change to work. 


Systems: The everyday policy, processes and procedures that need to be adopted in the ‘to-be’ 
state. 


And the ‘soft’ elements include: 


Shared values: Do the core organisational values support the next. environment going forward; 
do they need to be adjusted? 


Style: Of the leadership and supervisor teams: Is it ‘command and control’ when it should be 
about delegation and empowerment? 


Staff: What is the profile of the employees and their general abilities? 


Skills: Actual competencies (skills) of the employees: Do they need up-skilling or re-skilling in the 
‘tobe’ state? 


igure 15.13 Mc 





eo ir oe 


Step 1 Step 2 
Document the ‘as-is’ Step 3 Document the ‘to-be’ 


List of gaps to get the 
organisation and its 
employees from the 

‘ass’ (current state) to 

the ‘to-be’ (future state) 


Examples: 

1. Shared values. 
Adjust share 
values to include 
‘safety’ and 
relaunch the 
company’s values. 


2. Style. Re-educate 
the style of 
management to 
empowerment away 
from micro- 
management. 





3. Skills. 
Retrain staff in new 
software package 


Source: Exhibit from “Enduring Ideas: The 7-S Framework”, March 2018, McKinsey & Company. wwwmckinseycom. Copyright © 
2018 McKinsey & Company, Alll rights reserved. Reprinted by permission 
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A final tool that the authors often find to be useful at the Initiating stage of a project (and as 
a readiness check for the implementation of a change) is Lewin’s force field analysis (FFA), see 
Figure 15.14. 

Referring to Figure 15.14, it can been see how the project manager could leverage this tool in a 
number of situations. A typical sequence of events in the Initiating stage could resemble: 


1. The project manager, with the project team, crafts a project vision statement. 


2. The project manager holds a workshop with key stakeholders (managers and supervisors of the 
project's deliverables), and at this workshop they: 


(a) Brainstorm all the positive (‘driving’) forces for the change and rate each force on a scale of 1-10. 


(b) Brainstorm all the negative (‘restraining forces’) for the change and rate each force on a scale 
of 1-10. 


3. The project manager can then analyse the results of this brainstorming session and: 


(a) Review the positive forces, which indicate points that can be leveraged in the project. This 
analysis may result in the requirement for additional communications, the need to build 
relationships with stakeholders, or even include additional work packages in the project to 
address new work that has now been identified. 


(b) Review the negative forces, which indicate concerns in the project. This analysis may result 
in the requirement to log risks, issues or address the concern by including additional work 
packages in the project to address new work that has now been identified. 


(c) By reviewing the overall (total) scores of the positive and negative forces, the project 
manager can see which way the project is weighted and adjust strategies and approaches 
across the entire project accordingly. A higher negative score operates as a waming sign to 
the project manager to ensure each negative force is specifically addressed. 


There are many organisational change management tools at the project manager's disposal. 
Change management tools are used as part of the modern stakeholder management approach to 
ensure smoother acceptance by stakeholders who are to use the endproduct or service (or result) of 
the project. 


Figure 15.14 Lewir 
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Source: Lewin K 1943, ‘Defining the “field at a given time”, Psychological Review, vol. 50, no. 3, pp. 292-310 
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15.7 SCRUM/AGILE CONSIDERATIONS 


The Scrum approach to project management does not differ from any other project management 
approach. A Scrum project must engage with a variety of stakeholders at different times, in order to 
deliver outcomes to the customer. For example: 


= During interactions of a sprint, the development team will undoubtedly work with employees of 
the organisation (stakeholders) to define and refine stories and requirements. 


E The Scrum master has to ensure there is product owner (stakeholder) understanding and buy-in 
to the Scrum approach. 


E The product owner represents the business, and therefore would have interacted with 
stakeholders in the business in order to arrive at a prioritised product backlog. 


Summary 


Stakeholder management, with all its social and political complexities, can be the crux of many projects. 


Stakeholder management is closely associated with the knowledge area of project communication management 
(and the two are often considered together). Figure 15.1 indicates the cycle of activities that usually take place with 
each stakeholder—from stakeholder identification, through to stakeholder analysis, and the actioning of strategies 
resulting from this analysis. 

This chapter reviewed a number of tools that can be leveraged to identify, analyse and manage stakeholders (such 
as the Power/Interest Grid, the Contribution/Commitment Grid and the concept of stakeholder currencies). 
Stakeholder management integration starts from the word ‘go’ on a project and does not end until the project 
deliverables have been successfully handed over to the business and the project team has been disbanded. As with 
communications, stakeholder management can consume a large proportion of the project manager’s face-to-face 
time, but this is not wasted time. 

Project managers should recognise the importance of organisational change management (OCM) and the 
importance of the project manager’s ability to successfully embrace and promote OCM practices within the project 
environment—for example, leveraging commercially available techniques and regularly applying these techniques 
(e.g. ADKAR, Kotter, and the Change Leaders Roadmap, among many others that are available). Students are advised 
to independently learn more about these techniques. 





The project manager should not underestimate the importance of engaging with stakeholders and creating an 
environment of stakeholder co-creation. Time invested in quality stakeholder engagements will typically pay off in 
the long run. 


https://www.praxisframework.org/en/library/cohen-and-bradford 
https://www.pmi.org/learning/library/value-cocreation-Stakeholders-research-project-9529 
www.champs2.info 

https://www.jisc.ac.uk/guides/change-management 
https://www.kotterinc.com/8-steps-process-for-leading-change/ 
https://www.beingfirst.com 
https://www.beingfirst.com/services/change-leaders-roadmap-methodology/ 
https://www.prosci.com 

https://www.prosci.com/adkar/adkar-model 
https://www.mindtools.com/pages/article/newSTR_91.htm 
http://shop.bcs.org/resources/pdf/9781780172736.pdf 
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https://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/ 
enduring-ideas-the-7-s-framework 

https://www.Stakeholdermap.com/Stakeholder-matrix.html 

https://www.vtiger.com/crm/ 

www-saleforce.com 


action learning (variant of action law of reciprocity stakeholder co-creation (value 
research) McKinsey 7-S framework creation) 
ADKAR met expectations stakeholder engagement cycle 
Contribution/Commitment Grid organisational change stakeholder identification 
co-creation management (OCM) stakeholder network diagram 
currencies organisational development Stakeholder Register 
cycle Power/Interest Grid sustainable development 
Fisher’s personal transition curve primary stakeholder value proposition 
force field analysis (FFA) rich pictures What’s in it for me? (WIIFM) 
internal/external stakeholder secondary stakeholder 
identification stakeholder 


Review questions 


What is the ‘network of stakeholders’? Why would you develop one as a project manager? 

What is stakeholder co-creation? 

What information would be included in a typical Stakeholder Register? 

Why is it important to build trust with stakeholders? 

What does mapping stakeholders in the Contribution/Commitment Grid enable the project manager to do? 


au ewns 


How can organisational change management assist the project manager? 


4. Use one of the stakeholder identification techniques, discussed in this chapter (refer to Figures 15.7A, 15.7B, 15.7C, 
15.7D and 15.7E) and brainstorm who the various stakeholders are for a current project you are involved in. 

2. In your groups (for your case study), draft a Stakeholder Register (including a Power/Interest Grid and a Contribution/ 
Commitment Grid). Using all of this information, next carry out a stakeholder analysis, and then make recommendations 
as to what stakeholder strategies you would capture against each stakeholder. 

3. For the ADKAR template (Figure 15. 15): 


(a) You are to adopt the role of an end-user (or customer) for a project you have recently been involved with. For each 
question in column 3, complete the corresponding blank in column 4 and then score each question in the circle 
shown, based on the scoring criteria provided. 


(b) Next, review the results you have captured with a ‘project manager's hat’ on and answer the question: ‘What do 
these results tell you about the change acceptance of your project?’ 
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PROJECT INFORMATION AND 
COMMUNICATIONS MANAGEMENT 





Learning elements 


Understand the communications context for a project. 


Identify and plan communications for a project, given the range of stakeholders 
that exist on a typical project. 


Understand various project management information systems including tools that 
support the social media element of project management. 


In this chapter 


16.1 Introduction 

16.2 Communication and project management 

16.3 Communication models 

16.4 Further communication considerations 

16.5 The Communications Management Plan 

16.6 Planning, developing and tracking communications 
16.7 Project reporting 

16.8 Project Management Information Systems (PMIS) 
16.9 Scrum/Agile considerations 


Summary 
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16.1 INTRODUCTION 


Stakeholders, communications to stakeholders and the sharing of project information are all 
interconnected. This chapter focuses on the information and communication aspects, with a more 
detailed discussion on project stakeholder management in Chapter 15. Some of the communication 
and project information activities that will be discussed in this chapter are illustrated in Figure 16.1. 
Although not a flowchart, it does depict how activities are related to each other and where we are 
most likely to see these activities occurring in relation to the project management life cycle. 


16.2 COMMUNICATION AND PROJECT MANAGEMENT 


The topic of communication covers internal team communications, stakeholder communications and 
project reporting. The Stakeholder Matrix (referred to in Chapter 12) forms a useful starting point 
from which to consider project communications, but it has some limitations when used with more 


complex projects. 

Remember: As with stakeholder management, project communications involves a two-way 
dialogue (or a multi-way dialogue) between two parties (or more). As highlighted in Chapter 7, 
communications can make or break a project, and a lack of, or a breakdown in, communications is 
frequently quoted as being a point of failure in projects. 


Figure 16.1 
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Some dynamics of project management communications 


are indicated in Figure 16.2. These are just a few of the dynamics Figure 16.2 Dynami 





however that a project manager must provide answers to, ona 


communication by communication basis. Internal GE External 
Figure 16.3 shows the dimensions of ‘upwards’, ‘downwards’, 
‘horizontal’ and ‘outward’ communications that a project Formal GE Internal 


a‘ i ie ANA 
manager has to consider when ‘targeting’ communications to Vertical pepee Horzental 


the various levels of an organisation. When a message is sent, 


it will be communicated in different ways—the wording of the Official Q Unofficial 
communication will (often) need to be adjusted for each level, : 
Weiter < a or 


as appropriate. Ensuring that everyone in the project team is 


‘singing from the same song sheet’ is critical to the project. Verbal Q Non Verbal 
The authors have been in a position where incongruent, 
inconsistent and inaccurate stories of the project were received ea Q ees 
by senior stakeholders from project team members and in 
these situations it was necessary to intervene rapidly to avert 
issues for the project. 
Planning and addressing hew project communications will take place with the various stakeholder 
groups in a project is sometimes either overlooked or insufficient attention is paid to this dimension 
of the project. Care and attention needs to be devoted to development of the Communications 
Management Plan (discussed later in this chapter) and the associated ‘living’ project communication 
documents to ensure the medium(s), tools, methods, timing and hierarchies of communication are 
fully understood and documented for later development and distribution during the Executing stage 
of the project. 


16.2.1 Communication challenges 


Project communications issues frequently appear on project failure lists. However, to understand more 
deeply the point of failure is key to ensuring that lessons are learned and not repeated. Unpacking 
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communication issues further could result in identifying some of the more commonly experienced 
challenges involved with communication, including: 


E Lack ef ceommunicatien: Symptoms of lack of communication include flapping and statements of 
uncertainty being made by any stakeholder. 


Em Miscemmunicatien: This can manifest in many forms, for example, by not spending enough time 
developing and reviewing communications prior to sending them to selecting an inappropriate 
medium for the communication. 


— Timing of communication: As with all aspects of communication, the timing of events is critical. If 
the communication is sent too soon, the message may be forgotten or may lose impact. Send it too 
late though, and the receiver(s) may not have sufficient time to make any necessary arrangements. 
A useful technique from practice is to include communication tasks on the project schedule and 
highlight these in a differently coloured overlay to indicate the importance of planning, reviewing 
and sending project communications. 


— Forgetting aspects of non-verbal communication: Non-verbal communications make up around 
55 per cent of all communication, so selecting the correct medium is critical to project success. This 
is especially true during the Initiating and Planning stages of the project, where people first engage 
with each other within the project environment. Gestures, tone and facial expressions alone can 
portray a vast range of meanings (which we often miss in the world of social media-driven commu- 
nication strategies). 


E Tee much cemmunicatien: Just as there can be a lack of communication or there may be 
miscommunication, there can also be tee much communication; this too can be detrimental to 
the project. Many employees talk of ‘information overload syndrome’ (IOS), especially in today’s 
busy project offices, where emails can seemingly bombard project team members. It’s important. 
therefore that the project manager is selective in what communications are sent, to whom, 
and when—to ensure any communications sent is attended to in an appropriate manner by the 
receiver of the communication (and not just ‘junkea’). 


Project communications need to be wellplanned. Like most elements of project management, 
quality time spent planning communications is seldom wasted. So, what are some of the benefits 
of paying careful attention to communication within the project? In their book Ceommunicatien: 
Yeur Key te Success, Taylor & Lester (2009) point out some of the potential benefits of having 
good communication within a project environment (per a project management context), 
including: 


E Reduced: Conflicts, rumour-mongering, misunderstandings, stress, errors and mistakes. 
E Increased: Productivity, motivation, cooperation and success. 


E Better (smeether ): Proble msolving, decisionmaking, image and reputation, and workflow. 


The challenge is therefore to ensure a planned and considered approach is taken by the project 
manager to ensure a successful outcome is achieved with the stakeholders. 


16.2.2 Pitching your project: The big picture 


At the outset (beginning) of a project, the big picture may unintentionally be forgotten as the project is 
‘chunked’ down into its relative components/processes. The simplest and most powerful way to ensure 
the project team knows and sends a consistent message about the project from the outset is to create 
a compelling project elevator pitch (EP). 

An EP is a condensed story of the project, that can be delivered (pitched) within 90 seconds. The 
concept of an EP was initially developed to enable a pitch to be quickly delivered to stakeholders 
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(a captive audience) while travelling up eight floors (of a typical office building) in an elevator. An EP 
typically answers the following questions (which are embedded within the story of the pitch): 


m Whatis the ‘pain point’ being experienced?—by the stakeholders? 
Who's sponsoring it and why?—alignment to the organisation's strategy 
What are the business outcomes?—a vision of the future 


How are we going to get to these outcomes?—the steps to be taken 


What's in it for me (WIIFM)?—the emotional tie back to the stakeholder. 


Ensuring all project team members are ‘singing from the same song sheet’ ensures a consistent 
message is sent by the project. This is a fundamental imperative and yet quite surprisingly, many 
projects fail to afford sufficient time to the development of a clear project statement that can be 
repeatedly delivered and understood by any stakeholder (regardless of their role or interest in the 
project, i.e. from executive to ontheground subject matter expert (SME)). 

Anexample of good practice was exhibited in a recent project one of the authors was working on, 
which was made up from nine other subprojects. Great success was achieved by not only having an 
EP for the wkele project, but also for each sub reject. This not only ensured clarity for the project 
team when developing the pitches, but also provided clarity for every stakeholder involved in the 
project by communicating the larger outcomes of the whole project, and the component focus of 
each of the subprojects. The pitches were subsequently captured in a project flyer and left with 
stakeholders after each meeting. (The flyer was also casually left in meeting rooms frequented by 
peer managers who were affected by the projects outcomes.) This example shows the creative side 
of project communications as the project manager has to continually review all methods used for 
communication to ensure maximum project publicity. 

A useful inclusion to have in an EP is the articulation of the link between the project and the 
organisation's strategy. By making a clear link to the organisation's strategy, there is clarity around 
the origins of the project and the benefits the project will deliver to the organisation. 


16.3 COMMUNICATION MODELS 


Communication methods can include face-to-face communication (e.g. interviews, brainstorming 
meetings and group meetings); announcements from within the project to outside (e.g. a newsletter 
emailed to stakeholders); and the setting up of channels through which outsiders can source 
information about the project (e.g. a database that stakeholders can access). Let's now move forward 
by considering three main styles of communications that come from within a project. These can be 
broadly categorised as: 


1. Interactive ceommunicatien. Often the most common type of communication, where two parties 
are in direct faceto-face contact. Most frequently meetings, information gathering sessions, 
workshops, focus groups, interviews and brainstorming sessions, amongst many other popular 
formats. It is often referred to as ‘rich’ due to the many dimensions it can take ranging from the 
verbals to the nonverbals in communication. 


2. Push cemmunicatien. Here communications are pushed from the project, the communication 
is more directive as opposed to consultative in nature and frequently there is little to no loop for 
feedback. Announcements would be a good example, where the decision has been made (with 
or without involvement of key stakeholders) with the act of announcing effectively pushing the 
information onto the recipients. 

3. Pull cemmunicatien. Here stakeholders pull the information required from published sources. 


For example, an intranet page could be established where stakeholders freely pull information as 
and when required. 
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Regardless of the type of communication style 
Figure 16.4 Lines of communication employed, a project manager must be cognisant 
, 


of the complexities that are involved with project 
communication as an endeavour. A frequently 
encountered communication model to be aware of 


Team A Team B 


as a project manager is lines of communication. 
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potential lines of communication within each team. 
Applying the formula 
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(where n is the number of people being communicated with) we can see that Team A has three 
lines of communication whereas Team B has 10 lines of communication. By adding only two people 
into the mix, the lines of communication have increased significantly. Now just consider this scenario 
on a project with 100 people! 

The discipline of project management often makes reference to the sender-receiver model and 
the SMCR model (otherwise known as ‘Berlo’s model’). 


16.3.1 Sender—receiver model 


The sender-receiver model, sometimes known as the ‘Shannon and Weaver model’ (Verdii & McLaughlin 
2000) articulates a simple model of communication. As we know, communication can only take place 
between two (or more) individuals (or groups). When the sender sends the message (regardless of 
the medium), the message is open to distortion, deletion, deflection or, more frequently, incorrect 
translation. Some organisations refer to this as ‘noise’, meaning that an intended message may not 
achieve its desired intent (see Figure 16.5). ®nce a message has been received and digested, the 
receiver will often seek clarification via a feedback loop. In a facet o-face situation the feedback loop 
can be as simple as the receiver saying, ‘Can I recap on what we have just agreed?’ But if the chosen 
communication medium is email, how does the receiver confirm or provide constructive feedback? 
Remember, communication is a two-way process. 


Figure 16.5 The se: 
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Although some critics have raised concerns about the Shannon and Weaver model, the author believes 
that these are situation-dependent in application; therefore, the project manager should also consider: 


E the impact if the communication is sent to multiple parties (e.g. a mass email) as the model 
assumes a one-to-one situation 


Æ potential variations in how the message will be interpreted (Remember: A person is an individual 
and their perspective may differ from the perspective of others’. This may also be compounded by 
cultural and other factors.) 


E the power-interest relationships of those at the receiving end of the message. 


16.3.2 The SMCR model (Berlo’s model) 


The SMCR model stands for ‘Source, Message, Channel, Receiver’ (see Figure 16.6). The SMCR model 
accounts for a variety of human variables that are present. in person-to-person communications. 
The SMCR model is often applied to the communication of emotionally complex messages. There 
is an assumption in using this model that the receiver should be on the same platform as the sender 
(to ensure a smooth flow of information). The receiver should have good communication skills to 
understand what the sender is trying to convey, have the right attitude, and a sufficient level of 
knowledge to be on-par with the receiver. 
The sender (or source) encodes the message to be sent. This involves: 


Communication skills: The individual's ability (skills) to communicate (e.g. their reading, 
writing, speaking and listening skills). 


Attitude: Towards their audience, towards the subject matter and even towards oneself. 
Knowledge: About the subject. 
Social system: Includes their values, beliefs (cultural), religion, and general ‘understanding’ of society. 


Culture: Within which, both ‘encoding’ and ‘decoding’ takes place. 
The message consists of: 


Em Content: The content of the message to be delivered. 


Elements: Aspects such as language, gestures, and body language. 


E Treatment: The way in which the message is conveyed/delivered. 


Figure 16.6 The 


Source 


* Sender encodes message 
using communication skills 
such as reading or writing 





CR model 


+ The content of the message 
is conveyed based on the 
use of verbal and nonverbal 
cues. 


Channel Receiver 



















* The five human senses are * The recewer decodes the 
used in effective message message using the same 
delivery. factors and influences that 

were used by the sender. 














They base this upon theit 
expertise and knowledge, 
attitudes, beliefs and value 
systems. 
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Source: Adapted from Berlo, D. (1960). The precess ef communicatien: An introductien te theory and practice, New York: Holt. 
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@ Structure: The structure of the message (i.e. how it is arranged). 


m Cede: How itis sent, and in what form. 


The channel provides an understanding of the senses used in the delivery of the message: hearing 
and sight (touch, smell and taste) are also a part of the model. 

The receiver of the message then decedes the message. All the elements of the sender or seurce 
(above) apply once more, given the assumption of the model (e.g. the receiver should be on the same 
platform as the sender). 

Shannon and Weaver’s model of communication and the SMCR model provide useful 
visualisations to assist with understanding the basics of communications theory and they provide 
a worthwhile insight into how some forms of communication may be constructed. Although it 
would be practically impossible to apply the models to every type of formal project communication, 
the principles of the models nonetheless provide a good understanding of the dynamics of the 
communication process. 

So far, this chapter has provided a general background to ‘communication’ having looked at some 
examples of communication models that are often referenced by the project managers. We must bear 
in mind, however, that before identifying a suitable plan for project communications, the project 
manager needs to first identify and analyse the project's stakeholders. (Chapter 15 discussed activities 
involved in identifying and managing often-complex networks of stakeholders.) In communicating 
with the stakeholders, the project manager and project team members should be aware of the non- 
verbal side of communications and the importance of picking up on these non-verbals as a part of the 
holistic approach to communications. 


16.4 FURTHER COMMUNICATION CONSIDERATIONS 


This section will review some older but still highly relevant. aspects of communication, such as non- 
verbal communication and learning styles through to more-modern aspects of communication, 
such as generational differences and cultural considerations. The reader is also encouraged to 
revisit the ‘trust equation’ introduced in Chapter 14. 


16.4.1 Non-verbal communications 


Albert Mehrabian (who is Professor Emeritus of Psychology at UCLA in the United States) writes 
about non-verbal communication in the following way: 


Our speech-erientated culture is just beginning te take nete ef the prefeund and everleeked 
centributien ef nenverbal behavier te the precesses ef cemmunicatien. This centributien ef 
eur actiens rather than eur speech is especially impertant, since it is inseparable frem the 
feelings that we knewingly er inadvertently preject in eur everyday secial interactien and 
determines the effectiveness and well-being ef eur intimate, secial, and werking relatienships. 


Mehrabian goes on to suggest that: 


Peeple whe have a greater awareness ef the communicative significance ef actiens net enly 
can insure accurate cemmunicatiens ef their ewn feelings but can alse be mere successful 
in their intimate relatienships, in... werk that invelves the persuasien, leadership, and 
erganizatien ef ethers. (Mehrabian 1972, p. 2). 


Mehrabiar’s ‘7-38-55 Rule of Personal Communication is illustrated in Figure 16.7. The percentages 
of 7, 38 and 55 are supported by lists of potential behaviours that might be experienced by a 
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Source: Mehrabian 1972. List oftraits compiled by Dr. Neil Pearson 2018 


project manager or by a stakeholder during an engagement. In the Barlow sender-receiver model, 
‘communications’ were being sent and received; here, in the ‘7-38-55’ model, what is being sent and 
received are the nonverbal cues. 

Nonverbal cues are classified into: touch (haptics), body language (kinesics), distance (proxemics) 
and voice (paralanguage). Bearing this in mind, reflect on how you, as project manager, might 
interpret what is being communicated in the fellowing scenario: 


A stakeholder is sitting across the table from you with their arms folded and they are 
predominately looking at people who are walking past the glass-walled meeting room. The 
stakeholder glances at you briefly from time to time. Their notepad is closed and their pen 
rests on top of it. In response to your question, ‘How are you feeling about working with me 
on this project?’ they say, ‘I really want to work with you in this project’. What do you as 
the project manager read into this situation? What's the non-verbal takeaway message(s) 
potentially being communicated? 


There is a dichotomy of behaviours going on here, both verbal and non-verbal and so you, as 
project manager, would need to probe further to establish whether your hunch is correct. 

The PMI recognises the importance of nonverbal communication. It makes various references to 
non-verbal communication, including: 


@ as a must-have skill of the project manager 
m in dealing with stakeholders 


m in communications. 


There are many examples of nonverbal communications, including body language, eye movement, 
physical gestures, voice tone and facial expressions. The ‘art and science’ of picking up cues used in 
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Figure 16.8 Visual, auditory, kinesthetic (VAK) reported 


styles of learning 





Visual 
65% 


non-verbal communication is captured in the neuro-linguistic programming (NLP) approach to 
communication. NLP is: 


... used fer persenal develepment and fer success in business. NLP is the practice ef 
understanding hew peeple erganise their thinking, feeling, language and behavieur te 
preduce the results they de. (NLP Academy 2018) 


When you next meet with stakeholders, project team members, or the project sponsor, in your role 
as project manager, try to be cognisant of not only what they are verbally saying to you, but also what 
their nonverbal cues may be telling you about what they are really thinking! Even when trained in the 
art of NLP, being able to practise NLP skills ‘in the moment’ can take time to master. However, it is a 
communication skill that can help to provide a well-rounded understanding of what a person is saying 
and what they are indirectly saying (therefore ‘communicating’), which can help to foster a more in- 
depth understanding of their true message and move towards a more trusted relationship with your 
stakeholders. 


16.4.2 Learning styles 


There are many different learning styles. Getting the best out of people necessitates being able to 
assess and understand how project team members, the project sponsor and other stakeholders learn. 
This knowledge can benefit a project manager as it means they can tailor communications to be more 
engaging for their audience. 

Fernald, Keller, Orton, Gillingham, Stillman and Montessori were some of the first psychologists 
and teaching specialists to develop (what is popularly known as) ‘the VAK model’ (Visual, Auditory, 
Kinesthetic) in the 1920s. The model depicts how individual learning styles influence the way a person 
learns and the distribution of learning styles found in the general population. Figure 16.8 illustrates the 
observed reported styles of learning. 

If a project manager is struggling to communicate effectively with a group of individuals (or a 
single individual) they should consider whether this is because the person(s) doesn't actually fall 
into the 65 per cent population group of visual learners, but instead naturally use either an auditery 
or a kinesthetic style of learning. This fascinating area of work became a research focus for Neil 
Fleming (of New Zealand). In 1987 Fleming became the first person to systematically present. a series 
of questions that could be used by teachers, students and employees to work out individual learning 
styles. Fleming added a fourth mode—readingAvriting—and the model became known as VARK 
(Vark Learn 2018). 

Fleming’s VARK questionnaire can be accessed at: http:// 
varklearn.convthe-vark-questionnaire/. This questionnaire 
is helpful for investigating situations such as the one 
outlined above. Why not try the survey for yourself and 
investigate your own learning style? 

Auditory Kinaesthetic Bearing in mind earlier discussions about non-verbal 
i oe cues, let's now consider how an individual's learning style 
could potentially be revealed by their use of non-verbal cues. 
Take a look at Table 16.1 for some suggestions—remember 
the NLP approach introduced earlier in this section, which 

would teach you how to pick up on such cues. 


16.4.3 Generational communications 


By the year 2020 there could be five generations working 
side-by-side in the workplace. Project managers will 
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Table 16.1 What VAK can help to tell us about stakeholders 


Learning style Watch their eyes Listen to what they say 


Visual (see it) Looking upwards | get the picture. 


| can visualise that. 
| see how it works! 
I see the landscape you’re working in... 


Auditory (hear it) Look straight ahead That rings a bell! 


Sounds good to me. 
| hear what you're saying. 


Kinesthetic (do it) Looking downwards That feels about right. 


How does that grab you? 
Let metry... 


have to create environments where multiple ways to communicate will exist to ensure engagement 


occurs successfully across the five generations. This will necessitate being cognisant of different 
communication styles and preferences, given that each person is highly likely to be more comfortable 
using the communication style that their particular generation grew up with. 


Table 16.2 represents commentary that has been collected from various resources. It is presented 


as a ‘heads-up’ for project managers regarding what to be cognisant of when they are involved in 
working out ‘information and communication’ requirements in a project environment. 


Note: It is important that the project manager always consults with the project team directly to 


ascertain and agree on the overall ‘preferred’ information and communication style. 


16.4.4 Cultural differences 


The topic of ‘culture’ has been discussed in Chapter 5. Three perspectives of culture often experienced 
by project managers are: 


le 


Preject culture: This is established by the project manager to build an open, honest, transparent 
and trusted environment that project team members and engaged stakeholders can work within. 
The project manager establishes and enforces the project culture. 


Organisatienal culture: This comprises the values, structures, politics, agendas and leadership 
styles (among other factors) that influence the project culture (and the culture into which the 
final product, service or result will be deployed). The project manager has limited control over 
the organisation's culture but may be able to influence it in a positive manner through the good 
behaviours of the project team. 

Internatienal culture: This impacts how stakeholders behave and how information is interpreted 
across international boundaries. 


These ‘perspectives of culture’ will influence all types of communication: 


Written repert er decument: This includes the words used and how these are translated 
(interpreted) by the receiver, whose native language might not be the same as the sender's. 


Face-te-face meeting (where a nod might actually mean ne/): Differences in cultural nenverbal 
cues should be thoroughly researched and understood prior to faceto-face engagement to save 
face from any potentially embarrassing faux pas and misunderstandings occurring. 


Virtual meeting: If one of the communication ‘feedback channels’ is missing (e.g. non-verbal cues 
cannot be seen), how can we be sure that discussions are being interpreted correctly by either party? 


Contemporary project managers must consider at least all of the above aspects when developing 


the strategy to be used for information sharing and for communication (as documented in the 
Communications Management Plan). This also applies to the development of the communications 
themselves (as documented in the Communications Sent Register). Project managers must take care 


Table 16.2 Information and communication preferences across generations 


Generation 


Date range (approx.) 


Defining events and 
technology 


Communication trends 


Career expectations 


Meeting medium 


ate 


Silent generation 
(traditionalists) 
1925-1945 


Automobile 
Wartime rationing 
Defined gender roles 


Formal letters 
Written communications 


Job for life, security, loyalty 
to the organisation 


Face-to-face, let’s have a 
conversation 


M 


Baby boomers 
1945-1960 


Television 

Landing on the moon 
Cold War 

Freedom of speech 
The nuclear family 
Nuclear arms race and 
superpower play-offs 


Telephone 


Organisational careers, loyal 
to the company, climbing the 
corporate ladder, ability to 
work from home 


Call me on my phone, and 
let’s have a conversation 


A 


Generation X 
1961-1980 


Personal computer 
Compact disc 

Early mobile technology 
Dual incomes and greater 
independence from the 
nuclear family 

Dial-up internet 


eMail and text messages 
(SMS) 


Loyal to the profession, not 
the employer 

More flexibility in working 
arrangements 


Online, send me an email 
and we can meet if required 





y 


Generation Y (millennials) 
1981-1995 


Tablets and smart phones 
9/11 

Reality TV 

Google 

Online social movement 
groups 

Born into the internet 
(‘digital natives’) 
High-speed internet 


Text messages and social 
media 


Entrepreneurs 

Digital working 
Dependence on instant 
feedback and gratification 
Over-compensated 


Online face-to-face 
conferencing 

Information length and 
depth starts to reduce -a 
move to Google approach; 
don’t waste time on details 
I can find it if | need to 


Generation Z 
(T Generation) 
Born after 1995 


Artificial intelligence 

3D printing 

Global warming 
Crowdsourcing 

Social media 

Always-on internet (over 
mobile data) and social 
media platforms 


Hand-held communication 
devices 


Pop-up businesses 

Move around organisations 
freely and frequently 
Confident but without 
experience 


Online, social media 

Smaller and ‘small-chunks’ of 
information without depth 
Social consequence of 
online communication 
decreasing the ability 

to successfully meet 
face-to-face in a business 
environment 


Source: In addition to the authors’ experiences in engaging with multigenerational work environments, the various Internet sources referred to in the compilation of this table are included in the weblinks section of 


this chapter 
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SNAPSHOT FROM PRACTICE Culture shock! 





One of the authors of this book (Pearson) was involveal in 
a strategic planning project for a Pacific Islanel community, 
which involved working with government staffanel community 
stakeholders. After the project hae concluded, he reflected 
back on lessons he hae learned about information and 
communication management by contemplating the following 
questions: 


What went well? 


m Meetings: Trying to arrange faceto-face meetings with 
some of the stakeholders was like trying to herd cats. 
What was found to work well was physically getting out of 
the office to meet stakeholders on their own turf. Despite 
it being avery hot and humid climate, making the effort 
to go out to the environments in which stakeholders lived 
ane worked, exhibited commitment and a willingness to 
experience and take part in their culture. This garnered 
their respect and buy-in to the project. 


= Communication with language: Recognising and 
adjusting to the fact that English was a second 
language on the island ane understanding that 
communication involved more than just words alone, he 
canvassed the assistance of a long-term islander when 
seeking ideas about how to communicate the final 
outcomes of the project. As a result, it was agreed that 
it would be culturally accepted if the final presentation 
was made to the whole department at various morning 
teas using a narrated PowerPoint. The stakeholders felt 
respect was demonstrated for their input to the project 
by being invited to the morning tea(s) and narration 
was carried out by various members of the community 
to demonstrate buy-in. Photographs were use@ to 
illustrate the relevance and benefits of the project to 
the community within the presentation. 


= Communication beyond the written word: It was 
necessary to think outside the box about how to 
communicate with some stakeholders, as some were 
illiterate (but very ‘switched-on’ individuals). This hae 
the potential to render communication about some 
ideas challenging for the project manager but he 
adapted his communication style to the situation by 
using descriptive narrations, visuals (photographs, 
drawings), non-verbal cues, ‘stories’ ane making sure 
that verbal communication took precedence over any 
written report or annotated chart. 


What didn’t go so well? 


m it was difficult to foster a deep understanding of 
existing island politics and the hierarchical clan-based 
culture that existed. It made the pro ject feel like it had 


only a cursory understanding of the environment. 
Given the short period of time that the author was in 
contact with stakeholders a lot of cultural information 
had to be absorbed ane acted upon correctly. 


What could be done better next time? 


m To deeper understand the actual ability of the 
managers to achieve corporate targets in at times a 
tough environment (politically, culturally, physically 
ane environmentally)—where targets had never 
realistically been applied to any role in the past. 


Successful communication was possible because trust 
was developed between the project manager ane the 
community (stakeholders). To build trust, the assistance of 
respected community members (including several elders) 
was gained ane they came together to deliver the key 
project messages to their departments ane the wider 
community. In addition, a script was created for the final 
presentation, which local people took turns to narrate (each 
representing an allocated government @epartment/area of 
interest). Although a simple idea, the cross-engagement 
between community aned government (departments) 
created a positive rapport and a commitment to the 
project's goal. This, in turn, helped to break down some 
barriers between the community ane government officials. 

Figure 16.9 shows a sample slide (one of many) 
from the final presentation, which was narrated by a 


Figure 16.9 Example of a narrated slide, as used 


during the final communication stage 





THEMES TO DELIVER OUR OBJECTIVES 





Community Engagement 


This theme encompasses greater transparency and engagement of 
the community by establishing repeatable communication 
channels. Providing Sections with a platform to engage and 
share information with the community on available services. 





Source: ® 2018 Dr Neil Pearson 
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government department member who was alsoamember you meet them, can facilitate successful ongoing project 
of the island community. communication. For example, it's easy to ask them 

Taking the time to find out about a stakeholders whether they would like to have information on the 
preferred way of receiving and sharing information, for project shared in the form of a status report or a short 
example, by asking them some simple questions when weekly meeting. 


to ensure that messages are not ‘lost in translation’ and should work towards all communications being 
as culturally and linguistically unambiguous and neutral as possible, so as to not unintentionally put 
stakeholders offside. This can be tricky to achieve, and ‘miscommunication’ and ‘misinterpretation’ 
are regularly cited as reasons with projects failing on the basis of communications. 


16.5 THE COMMUNICATIONS MANAGEMENT PLAN 


As with the previous knowledge areas that have been discussed, a management. plan should be 
developed prior to planning and developing communications. The Communications Management 
Plan (CMP) is typically developed during the Planning stage of the project. Artefacts such as the 
Stakeholder Matrix and a communications risk analysis would typically be considered within the 
Initiating stage of the project. 


A typical Communications Management Plan includes the following sections: 


Em Communications strategy and approach: This section of the plan describes the general strategy 


and approach to communications management within the project. For example, in a community- 
based project, you would describe what the general approach to communicating with the 
community will be. Note: This is not the place for detailed communications identification and 
planning, as this takes place in the Communications Matrix (discussed later in this chapter). The 
intention here is to conceptualise the overall approach to be taken with individuals and groups 
(internal or external) to the organisation. 


Policy and procedure: Identify any relevant organisational communication and marketing 
policies and procedures that have to be applied within the project environment. The 
organisation may have style guides that have to be followed for all corporate internal/external 
communications. There may also be guidelines on the use of logos or trademarks and processes 
to follow in relation to the development of any external marketing collateral. 


Project reporting arrangements: Detail the project reporting requirements, including all status 
reports that are to be generated by the project, who these are for, and their frequency (see 

Table 16.3 for an example). Also refer to Chapter 11 for a more detailed discussion on project 
control reporting. Note: It is common practice to include blank template reports as appendices 
to the Communications Management Plan—the format of these reports having been agreed to by 
the project manager and the recipient of the report. 


Project team directory. In addition to the stakeholder contact information contained in the 
Stakeholder Matrix, it is useful to capture all of the project team’s contact details. This may include 
phone numbers and email addresses not available outside of the project team. Another useful 
aspect to consider is the contact'’s availability. For example, does the project require a 24/7 contact 
person or (alternatively) on-call arrangements? A simple table (as illustrated in Table 16.4) would 
suffice for this. The authors experienced times on projects where the availability of key project 
staff during go-live weekends (of large ICT systems, for example) is required. It is therefore useful 
to capture formal details of these arrangements within the Communications Management Plan. 


CHAPTER 16 PROJECT INFORMATION AND COMMUNICATIONS MANAGEMENT 


m Cemmittec/preject meeting arrangements. Identify and document the project's formal meetings 
(e.g. who is to attend and the frequency and format of the meetings). Refer to Table 16.5 for 
an example. Also include a committee charter for each committee as an appendix to the 
Communications Management Plan (once developed and agreed by the committee). In addition to 
the committee's objectives, the charter should include the quorum of people required and motions 
to be passed/decisions to be made at the meeting. Another good practice is to schedule the 
meetings for the whole project at the outset, using the organisation's calendar system. This gives 
maximum notice to required meeting attendees, with the aim of hopefully avoiding conflicts with 
their availability later on, as the project progresses. 


E Cemmunicatien reles and respensibilities: This section should describe all the roles and 
responsibilities of the communications function within the project. This could be presented as a 
narrative; or a supporting category could be created in the RASCI Matrix (discussed in Chapter 6) 
and either cut and pasted into this document, or referenced from this document. Refer to 
Table 16.6 for an example of a RASCI covering two simple business rules. 


E Review precess. As illustrated in the simple flowchart in Figure 16.10, documenting the review 
process up-front ensures that the message has the best chance of being received in the manner it 
was intended. This is especially important for fermal external communications. 


E Preject Management Infermatien System (PMIS): The PMIS details the project's information 
management systems to be used within the project. This could range from corporate ICT systems 
to more specific project-related information systems. The project manager should also consider 
the security of access to these systems, as much of this information will be confidential to the 
project team, or even to specific roles within the project team. 


E Risk review: Review any communication activities to be carried out and identify risks. Ensure 
these are captured within the project's Risk Register. Either reflect those risks in this part of the 
Communications Plan or make reference to the Risk Register. 


E Lessens-learned. Ensure that a review of any lessons-learned from prior similar projects is 
carried out and that any relevant lessons-learned are entered into the Lessons-Learned Register 
under the category of ‘communications’. Alternatively, document the communications lessons- 
learned within the Communications Management Plan. 


Source: ® 2018 Dr Neil Pearsen 


Table 16.3 Project reporting requirements 


Report Who Frequency Format 


Executive tracking report Executive management Monthly Refer CMP Appendix X 
Project status report PMO Fortnightly Refer CMP Appendix Y 
Team progress report Project team Weekly Refer CMP Appendix Z 


Note: CMP = Communications Management Plan 
Source: @ 2018 Dr Neil Pearson 


Table 16.4 Project team contact information 
[Roe OOOO O Name Email(S) Phone number(s) Availability 
Project manager Sarah Jones s.jones@company.com.au + 61 XXXX XXX XXX 8 am -38 pm incl. weekends 
Project officer John Smith j.smith@company.com.au + 61 XXXX XXX XXX 8 am -4 pm weekdays only 
Database administrator Ellen Jones e.jones@company.comau + 61 XXXX XXX XXX On-call 24/7 
Source: @ 2018 Dr Neil Pearson 
Numerous project details will have to be raised, discussed and resolved when defining the 


Communications Management Plan. Documenting these within the Communications Management 
Plan will provide a point of reference for everyone in the project team. 
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Figure 16.10 
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Source: @ 2018 Dr Neil Pearson 


Table 16.5 Project meeting(s) schedule 


CE 


Team meeting Project team 
Project manager 


Technical review meeting Project manager 
SME 


Project technical lead 


Note: CMP = Communications Management Plan 


Table 16.6 Communication RASCI 


Rule/Decision 





7s), Approval of communications to Comms 
external suppliers 
24. Approval of external community Comms 


engagement communications 


Source: @ 2018 Dr Neil Pearson 





Frequency 


Fortnightly 


Category 


Peer review in project 
team 





Revision 
required 
OK 
PM Approval 
Return to 
any 
previous 
Revision. stage as 
Cr a advised 
OK by the 
project 
manager 


Communication issued 





Format 


Fridays 
Calendar invites established 


Communication filed in 
project library 


Communications Sent 
Register updated 


Communications 
Sent Register 





Feedback monitored and 
appropriately responded 


to by nominated project 
team member 





Committee/Meeting Charter 
Refer CMP Appendix 4 


Apologies to the project manager 


As required 


Refer CMP Appendix 5 


Project technical lead to build 


relationships with SME 


Comments 


i 
E 
T £ 
= 2 
© 
E a 
z T 
is) U 
Sn E-A 
2 2 
a a 
A R 
Cc c R 











D £ £ 
[z ° © 
7 = = 
© © 
oo v.l ti] 
E Ze Es 
E wo v 
SE 2 oz bei? 
vE a gE oEs 
i IS 55 |eés 
ao 72) Oo one 
| C R 
l A R 


CHAPTER 16 PROJECT INFORMATION AND COMMUNICATIONS MANAGEMENT 


16.6 PLANNING, DEVELOPING AND TRACKING 
COMMUNICATIONS 


Previous discussions about the Communications Management Plan provided guidance around the 
governance, process, roles and responsibilities of communications. These earlier discussions in 
developing the Communications Management Plan will have therefore paved the way to the planning 
of each (formal) communication from the project, who authors the message and who is the receiver 
of the message. 

The Stakeholder Matrix (a detailed list of what communications are planned to be sent) is a good 
place to start a review of communications. Figure 16.11 illustrates the typical project management 
artefacts thatare considered at this stage inthe communication planning process: the Communications 
Management Plan, the Stakeholder Matrix, the Communications Matrix (planned 
communications) and the Communications Sent Register (a library of sent communications). Note 
that many other project management artefacts also input into the communications planning process, 
such as the scope document, culture assessment, work breakdown structure and organisational 
process assets. 

The process of planning communications is next taken a step further by reviewing the contents 
of the Communications Matrix (a list of planned communications). It is important to note that 
for simple projects, there is normally a strong correlation between planned communications 


Figure 16.11 p ng artefacts 
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and identified stakeholders. However, in more complex projects, there may be other project 


communications that cut across different groups of stakeholders to present a unified message. The 


starting point for this next planning activity is assumed to be the Stakeholder Matrix (ie. a list of 


all stakeholders who have a stake in the project). Building the Stakeholder Register is discussed in 
detail in Chapter 15. 


The Communications Matrix helps the project manager to identify and capture formal 


communications that are planned to take place against each stakeholder. Refer to Table 16.7 for a 


simplified example of a Communications Matrix. 


Some of the main information that might be captured within the Communications Matrix is 


explored in the fellowing bullet list: 


Message sending: This is probably the most important field as it should describe WHY and 
WHAT message is being sent. For example, ‘status update’ does not provide the WHY, and a more 
suitable response could be ‘Weekly pregress reperts en an infermal basis te enable a swifter 
decisien precess’. 


Stage: Captures the project life cycle stage within which the communication is planned to be sent 
(or all stages). By reviewing the planned communications by stage, the project manager can 
assess the total communication commitment required by the project. This in turn may influence 
decisions around what communication assistance might be required. 


Respensible fer authering: Who in the project team is responsible for writing the communication? 
If the project manager decides to add tasks to the schedule (and/or work breakdown structure), 
requiring a communication be prepared, the responsible resource can then be allocated to the task. 


Reviewer: Who in the project team or in the general business community is to review the 
message? Referring back to the communication models introduced earlier, if the project manager 
can bring stakeholders in the business on board to review (from the business perspective) the 
communications being sent from the project, this should (in theory) narrow the gap between the 
‘sender’ and the ‘receiver’. 


Apprever: Who in the project team is responsible for signing off the communication? (In most 
circumstances, this would be the project manager.) 


Methed ef feedback: The simple sende rreceiver model of communication highlighted the notion 
of a feedback loop (refer to Figure 16.5). The planned method of feedback should be captured 
against each communication and appropriate arrangements made for reviewing and auctioning 
this feedback. 


Some common vehicles (channels) for giving feedback include: 
— phone—calling a project team member directly 


— email—to an individual project team member's email account or, often more frequently preferred, 
to a generic email account that can be monitored by any nominated project team member 


— call centre—in some large projects, the organisation's internal or external service desk might be 
briefed to answer calls 


— social media—if social media channels have been established by the project (e.g. ina large 
community-based project targeting generations Y and Z), these will need constant monitoring. 


Respensible fer menitering feedback: The person(s) nominated (with regards to the above bullet 
point) would be responsible for monitoring feedback and for taking appropriate actions. 


Medium(s): The selected mediums for the communication. Potential mediums could include 
email, fax, phone, web conference, video conference, voice conference, social media, TV, radio, 
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newspapers, flyers, posters, internet sites, intranet sites, signs, SMS, leaflet drops, and face-to- 
face communication (individual or groups). 


E Frequency: The frequency of communication (e.g. daily, weekly, monthly, ad hoc). 


™ Costs: Capturing the costs associated with the communication. In some projects, these could be 
substantial and would therefore have implications for inclusion in the project budget. 


So where are communications sourced from? Many techniques can be used for identifying 
communication requirements, including: 


E Sourcing frem the Stakeholder Matrix: This (as indicated in Figure 16.11) is the most popular method. 


E Sourcing from the WBS: In reviewing the WBS (the activities, tasks and work packages), the 
project team may be able to identify various communications requirements associated with the 
deliverable or work package. 


E Scope document: The project manager should always consider the original project scope and any 
commitments made in the scope document that require a communication consideration. 


E Communications manager: A different perspective might be achieved about project 
communications if a communication specialist is brought into the project. For example, perhaps 
a more holistic big-picture view of the project may be gained that had not been successfully 
captured in any of the detailed individual stakeholder communications. Some projects 
employ fulltime communications managers while others bring in the organisation's corporate 
communications manager to review the Communications Management Plan and Communications 
Matrix, to receive impartial feedback. 


Source: © 2018 Dr Neil Pearson 


Table 16.7 Example of a Communications Matrix 


Stakeholder l Message Medium Frequency Feedback channel Author | Approver | Direction 

Sponsor Project status Status report Weekly Email to project Project Project Project + 
report template via email (Thursday) manager officer Manager stakeholder 

Supplier Burndown chart Approved Daily Project manager Supplier Supplier Supplier > 

(software template via email collator for supplier project 

development feedback 

agency) 

User group Project newsletter Intranet site Weekly Email to project Project Project Project + 

officer officer manager stakeholder 

PMO Project status Status report Weekly Email to project Project Project Project + 

report template via email (Friday) manager officer manager stakeholder 


Source: @ 2018 Dr Neil Pearson 


In developing the Communication Matrix, you will notice that there are various multiplicities of 
communication. Typically, a communication multiplicity takes on one of three types, as indicated in 
Figure 16.12. 

During the Initiating and Planning stages of the project, identifying communications (while potentially 
carrying out communications) is a critical aspect of managing the project. Communication is a discipline 
in its own right, so any professional assistance that can be brought into the project environment will aid 
the overall writing, validating and distribution of communications from the project. 

@ne of the authors (Pearson) has experienced projects where key formal communications 
have been outlined, drafted, reviewed and agreed while building the Communications Matrix. This 
takes the planning of communications to a new level and is a definite move away from reactionary 
communications. 
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One communication could be f $ 
sent to multiple stakeholders 


One communication could be 
sent to a single stakeholder 


Many communications could be 
sent to a single stakeholder 


Source: © 2018 Dr Neil Pearson 


16.6.1 Developing communications 


Communications are typically developed (written) in the Executing stage of the project as they 
become due for sending. Many models exist which provide structure around the development of the 
communication content. These models include: 


m CPORT 


m The 4Cs of Truth about Communication. 


CPORT is a simple set of guidelines developed out of practice to assist in the development of 
communications. CPORT stands for: 

C = Context of the communication 

P = Purpose of the communication 

O = Objectives of the communication 

R = Resources affected by the communication 

T = Timing: When do the effects of the communication take place? 


CPORT acts as a checklist in the development of the communication. It is very much medium- 
independent so can be applied to any communication. 


Ina similar vein to CPORT are the 4Cs of Truth about Communication. 

The 4Cs of Truth about Communication are more substantial in nature than CPORT, being the 
subject matter of a book entitled: The 4Cs ef Truth abeut Cemmunicatien (Albanese 2007). Albanese 
describes the 4Cs in the following way: 


E Cemprehensien is the first C. Your message or ad needs to be quickly comprehended by your 
intended target. If you have to explain what your ad or marketing message means, it probably 
will be less effective. 


m Credibility is the secend C. Your brane’s message must make sense to the consumers relative to 
the way they perceive it. Consumers are smart and if you serve up a context for thinking about 
your brand that is completely implausible, you will lose them immediately. 
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SNAPSHOT FROM PRACTICE Mass email communications 





The consolidation of information ane communication 
technology is always on the books of growing large 
corporations. One of the authors of this book had the 
experience of working on a large consolidation project, 
involving the consolidation of a customer ticketing system, 
used by tens of thousands of customers ane supported 
internally by a user base of 15 000 employees (at all 
levels across the organisation). 

Communicating internally with 15 O00 employees 
provided an interesting challenge from the outset. 
Employees were located around the globe and were froma 
multitude of multinational and multicultural backgrounéds— 
although the business language was English. It was soon 
discovered, through delivering project communications, 
that English is not interpretea in the same way across 
the globe! In order to ensure a clearly identifiable project 
image, the author put together a standard format for all 
email communications, which included: 


Figure 16.13 CPORT style of communication 





an identifiable project logo and project name, to 
enable the user base to identify formal project 
communications above any ‘noise’ in the business 


an intranet site containing project information, 
copies of communications, FAQs (frequently asked 
questions) ane detailed technical and business 
process documents 


a pre-communicated format for emails. This was the 
most successful element of communications in the 
project. The format of emails was predetermined 
by the project (refer to the mock-up below) and this 
was communicated to all 15 000 employees on the 
distribution list 


a communications manager and a review process 
hat included business representatives from key 
countries across the globe. 








Sub ject: XXX: Project Name: 20 characters of informative text identifying the subject of the communication. 








Where XXX is one of: 

A: = Action Required 

E For Your Information 
U: = Urgent Action Required 





communications strategy for the project. 


The format of the email included the following headings. Note: These took on a CPORT style but were modelled on the 
sender-receiver model (i.e. a feedback loop was provided). The headings in the email were left so the reader could easily 
locate the information in the email. Further to this, the whole email had to fit within an 800 x 600 screen size with the 
complete message having to be visible without the receiver having to scroll. 


This template and the guidelines for its use were captured in the Communications Management Plan as part of the 








What is being announced? 
A short paragraph clearly describing the announcement. 


Who is affected? 


When will it take place? 


time zone. 


Where do I go for further information? 


Who do | contact for further information? 


The people affected by the communication. As the organisation did not have a comprehensive distribution fist, it was decided 
to send communications to the whole stakeholder group (le. the 15 000 employees), and to include this section of the email 
to indicate the various roles that would be affected by the communication. 


In this section a long date format was used and coordinated universal time (UTC). Additionally, a link was provided to a time- 
converter website giving the receiver the ability to calculate the date and time of the communication into their local country’s 


As the email message was constrained in length, the detailed instructions were developed in Microsoft? Word, exported to a 
PDF that was uploaded to the project's intranet site and a link (tested first!) inserted into the communication. 


in the majority of cases, this was always a real person and contact phone number. This was supported by a 'replyto' generic 
email address that was set up specifically for project communications. 











Source: © 2018 Dr Neil Pearson 
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m Connection is the third C. Consumers need to feel your message; they need to make a personal 


m 


connection with what you are saying. They need to viscerally respond, “that’s me 


E Contagiousness is the fourth C. Consumers need to feel energised and motivated to do something 
based on your message—whether it’s to pass on to their friends and colleagues, to think about 
your brand in a different way, to find out more information—whatever—they need to act 
(Albanese 2007). 


CPORT and the 4Cs provide a good basis for constructing the communications message. (Recall 
that a review process was included in the Communications Management Plan.) From experience: no 
matter how well the project thinks it has prepared a communication, the acid test will come from those 
who receive the communication. Hence, the importance of establishing a review process (that includes 
input from stakeholders in the business). You can read about the application of CPORT and the 4Cs 
to a large back-office consolidation project in Snapshot from Practice: Mass email communications. 

As can be imagined, the number of formal communications sent from a project across all mediums 
can be quite extensive. Keeping a record of ‘sent’ communications is just as critical as planning the 
communications in the first place. How many times have you, as project manager, been asked to go 
back to a communication sent three months ago on a project? How did you locate it? How much time 
did it take to find out who it was sent to? 


A handy resource a project manager may want to create is a simple Communications Sent Register 
that can be used to record all formal communications sent from the project in a list format. Table 16.8 
illustrates this kind of register. 


Source: ® 2018 Dr Neil Pearson 


Table 16.8 Simple Communications Sent Register 





Message Reference / link Medium | Who sent to |Feedback received |Feedback 
to a copy of the (distribution allocated to 
communication list or other) 
sent 

Monday 14 Notify users of Comms_Users_ eMail All company Sarah Jones, Project 
Jan2018 the project status, Organisation.doc employees suggested clarity by manager 
indicating what changes using diagrams to 

they will see to the represent changes 

organisation structure to the structure 


Source: @ 2018 Dr Neil Pearson 


This section has reviewed the process of identifying, developing and tracking communications. 
These activities could be distributed to various project team members, as indicated below: 


E The project manager could be responsible for instigating the communications strategy and for 
planning communications on the project. 


E The task of developing (writing) communications might reside with the allocated project team 
member and/or SMEs from the business working on the project. 


E The task of tracking and monitoring communications could be the responsibility of the project 
officer. 


Em If the project has a full or parttime communications manager allocated to the project, then 
it may be the case that the project manager devolves responsibility to them for all project 
communications. 


These roles/rules could be added to the project’s overall RASCI, to clearly indicate where 
accountabilities and responsibilities lie in relation to project communications. 
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16.7 PROJECT REPORTING 


A discussion of project reporting was initiated in Chapter 11, and descriptions were provided about 
a number of project reporting techniques. Chapter 11 covers the typical contents found in a project 
report (whether ‘full’ or ‘exception’) and introduces the technique of earned value management 
(EVM). The Communications Management Plan (as outlined previously in this chapter) would 
document details of the project’s requirements for reporting (refer back to Table 16.3). Some outputs 
of project performance reporting include: 


work achieved in the current reporting period 

work achieved against planned work (baselines for schedule, cost and scope) 
forecast of future work to be achieved (including time and cost) 

value of work achieved (using metrics such as earned value management (E'VM)) 
analysis of risks and issues 

summary of outstanding and approved change requests and the impact on baselines 


information on team health 


other information as required or mandated in the project reporting system. 
(PMI, 2013) 


Performance reporting of the project is crucial to communicating the status of the project to the 
project management office (PMO), the project sponsor, the steering committee and other stakeholders, 
as documented in the Communications Management Plan (and/or Communications Matrix). The 
majority of information on which the project status report is based will be distributed among the 
many other project artefacts that the project manager (and project team) will be maintaining as part 
of the dayto-day activity on the project. However, bringing this information together (compiling the 
report), validating the report (reviewing), distributing the report and fielding subsequent questions 
can be quite an involved process, which should not be underestimated by the project manager. In 
some cases, it may be advisable to include a communications task on the project schedule, as this will 
focus the project manager's attention on achieving any reporting deadlines. Remember, the project 
status report should be treated as a two-way opportunity to communicate with its recipients, and the 
project manager should actively seek feedback on elements of the report, such as changed risks and 
escalated issues. 


16.8 PROJECT MANAGEMENT INFORMATION 
SYSTEMS (PMIS) 


PMIS vary in their complexity according to their purpose. For example, complex tools might include 
the type of systems offered by Artemis and Primavera, whereas simple systems may involve the use 
of inhouse file-server-based project libraries. In today’s project environment, a PMIS is critical for 
being able to efficiently store, manage, search, distribute and maintain a whole host of projectrelated 
information. Projects typically not only include a myriad of project managementrelated documents, 
but also many thousands of artefacts that are related to the development of projectspecific content. 
Establishing a PMIS is an activity the project manager must consider at the outset of the project, to 
ensure a structured, easily accessible and central (authoritative) source of information exists. Some 
types of PMIS are discussed in the list below. Note however, in practice, a cembinatien of systems is 
usually utilised so that a comprehensive environment for storing and maintaining various types of 
project and projectrelated information is possible. 
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E Cerperate systems: These may range from the organisation's enterprise resource planning (ERP) 
systems, to financial systems. ERPs typically track information on work orders, packages of 
work and costs allocated. Finance systems may support the project in terms of managing the 
project’s budget and the reconciliation of purchase orders and invoices. They will also provide 
financial statements for the project. In some cases (when combined with scheduling information) 
EVM reports can be produced. 


E Scheduling and reseurce-management systems: Most high-end scheduling systems such as 
Microsoft®Project Server offer features far beyond the scheduling and tracking of tasks on 
a typical project. Most offer the ability to allocate resources and resource usage, and track 
progress and costs assigned to each task (work package) in the project. 


m File sharing: Most projects have a project library of some description, usually shared from a 
central file-sharing system provided by the organisation's ICT department. The project team then 
has the ability to create a file structure that is relevant to the project. Access to such systems can 
be tailored so that permissions to the subdirectories of information can be secured to particular 
groups of people within, and beyond, the project team. 


E Intranets: Systems such as Microsoft® SharePoint offer repositories for files while also offering 
features such as integrated calendars and the ability to create wikis, forums and blogs. Typically, 
these need to be set up and maintained by an administrator within the project. This is potentially 
responsibility of the project officer; however, the project manager must ensure the person 
allocated to this role has the necessary training to manage the system and to make maximum use 
of the features it offers. 


E Decument Management Systems (DMS) and Centent Management Systems (CMS): Both offer 
a high degree of formality in terms of managing artefacts (e.g. documents). Configuration 
management (CI) (see next section), workflow and document versioning are key features of these 
systems. Some of the more commonly encountered DMS include TRIM (a records management 
system, from HP®), Xerox Docushare® and OpenText® ECM suite. 


E Integrated PMISs: These are specific tools aimed at solving multiple aspects of information 
management in the project environment. These would provide facilities for scheduling and 
budget management (often integrated into corporate ICT systems), in addition to general 
configuration management (CI), reporting and information-sharing features. These systems also 
have the ability to manage information across the nine knowledge areas of PMBOK. As indicated 
previously, due to the complex nature of such a system, the authors advise on the integration of 
multiple systems that provide best-in-class features required by the project. 


16.8.1 Configuration management (Cl) 


As indicated above, the project could potentially generate thousands of artefacts, ranging from project 
management. documents through to test plans and code. The collection/development, analysis and 
dissemination of all these artefacts on the project requires some formality. Historically referred to as 
‘version control’, configuration management (CI) has now become the norm for the management, 
of the many and varied project artefacts, in anything but simple projects. The project manager has 
to decide which key artefacts will be subject to what levels of CI In its simplest form, CI could be a 
‘version’ and ‘distribution’ control added to the front of documents. For example: 


E Versien centrel aims to track the changes made to a document through the life of the project. 
The benefits to the project are a known state of a document, ensuring that when it is reviewed 
or approved, the readers/recipients are aware of which version is being reviewed and approved. 
This may take the form of a simple ‘version tracking table’ that is inserted on the front page of the 
document (see Table 16.9). 
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Æ Distribution control differs from version control. Distribution control involves tracking to whom 
(stakeholders) the document was issued, and on what date. Froma project perspective, this 
ensures that readership of controlled documents is clearly articulated and tracked. If a document 
has to be re-released or recalled, the author of the document knows exactly who to contact. 
Again, this may be in the form of a simple distribution-tracking table that is inserted on the front. 
page of the document (refer to Table 16.10). 


Table 16.9 Document version control 


Table 16.10 Document distribution control 


Version Released to Released by [Date = 


Note: Documents must not be forwarded to other parties without the prior consent of the document's author, 


When artefacts are placed inside a CI system, more complex measures will be applied by the 
system. For example: 


m Documents may only be checked out by approved people and documents must be checked-in 
once editing has been completed. 


E The document might be part of a workflow process, where the document is moved along a 
predefined workflow of people for editing and approval. 


=E The author will be responsible for maintaining the meta data (data about data) for the document 
such as its author, purpose and any key word search terms, and security privileges (among a 
whole host of other information). This facilitates being able to search and retrieve the documents 
at a later stage. 


Æ Version control will be applied by the system, creating the ability to be able to refer back to 
previous controlled copies of a document if needed. 


Administrators will have to establish role and security permissions in order to protect the 
documents within the CI system. 

PMISs vary widely. From a project management perspective, the concepts of ‘version’ and 
‘distribution’ control should always be considered when establishing a PMIS at the project Initiating 
stage. For simple projects, a manual version and distribution control is a minimum requirement and 
this is usually established and monitored by the project officer. For complex projects however, a PMIS 
can deliver many benefits, although of course the cost of the administration that will be required must 
be borne in mind. 
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As a final note to this section on document control and CI, the 
reader's attention is brought back to the discussion on quality. If 
your organisation is an accredited quality organisation that holds 
accreditations such as IS@9001, your project will have to inherit the 
organisation's Quality Management Systems in relation to document. 
control and CL The project manager may also wish to consider 
adopting best practice and standards for document management, 
within the project. Examples are ISO 10007-2017 Quality 
Management Systems—Guidelines for Configuration Management, 
and AS/NZS ISO 30301:2012 Information and Documentation— 
Management. Systems For Recordkeeping—Requirements. These 
are in addition to any legal requirements to which your organisation 
or industry is subject. 


rs of information 





16.8.2 Project knowledge management 


Before examining what knewledge is within a project environment, 
let's first take a look at some definitions of ‘data’, ‘information’ and 
‘knowledge’. The project manager must be able to differentiate 
between the different tiers of information in order to manage their sources and to capture 
information appropriately. Figure 16.14 indicates the tiers of data, information, knowledge and 
wisdom. 
Below is an excerpt from AS 5037-2005 Knowledge Management—A Guide: 


Data: Any manifiestatien in the envirenment, which may include symbelic representatiens 
that, in cembinatien, may ferm the basis ef infermatien. 

Infermatien: Data in a centext te which meaning has been attributed. 

Knewledge: A bedy ef understanding and skills that is censtructed by pee ple and increased 
threugh interactien with ether pee ple and with infermatien. The literature is replete with 
many centested definitiens ef knewledge. There is ne single agreed definitien ef knewledge 
er ene unifying theery ef knowledge management. Knewledge has many facets: 


m It canbe highly persenal and subcenscieusly understeed. Knewledge resides in a persen’s 
mind and may include aspects ef culture er ‘ways ef deing things’ (eften referred te as 
tacit knewledge). 


m It canbe recerded as infermatien in a decument, image, film clip, er seme ether medium. 


m It can be censidered as a cempenent ef an erganisatien’s asset base. (Standards Australia 
2005) 


Wisdem is often described as being ‘knowledge over time’. A fundamental challenge that project 
managers face (that is typical for operational managers across the business) is to be able to capture 
knowledge. Project managers need to consider two types of knowledge—explicit and tacit knowledge. 


m Explicit knewledge can be easily expressed and transferred between people without loss of 
meaning; it is usually recorded in some kind of medium such as a document, image, process or 
ICT system (e.g. in policy and procedure, manuals and process and operating procedures). 


= In contrast to explicit knowledge, tacit knewledge is difficult to articulate. It cannot easily be 
transferred without close personal contact, demonstration and involvement. Tacit knowledge 
refers to highly personal knowledge that resides in a person's head (mind) and includes physical 


CHAPTER 16 PROJECT INFORMATION AND COMMUNICATIONS MANAGEMENT 


skills as well as aspects of culture or ‘ways of doing things’. Importantly, tacit knowledge 
cannot be easily captured, but it can be transferred in discussion or via observation—much like 
apprenticeships. 


Most project managers are aware of project data, for example, the data elements of planned 
value and earned value. They will also be aware of the potential for information to be gained from 
an EVM analysis (a graph of the results that have been plotted). We know that to read the EVM 
graph, the reader uses known information about positive and negative variances (i.e. they use 
their knowledge). However, a project manager will actively apply their (potentially, vast array of) 
knowledge (i.e. wisdom) amassed over their entire career when making decisions on how best to, 
for example, get a project back on track. Wisdom is tacit. knowledge and is often hard to express 
and capture. 

But herein lays the challenge: How to identify knowledge that can easily be made explicit, and 
how to pass on tacit knowledge between the members of the project team. This is no easy task! The 
project manager can create an openenvironment where knowledge transfer is supported (and insome 
cases, rewarded). The project manager can initiate coaching and mentoring across the project, and/ 
or promote the use of various software tools, but at the end of the day it requires people to be in an 
environment where there is a culture of knowledge sharing. Remember: When we impart knowledge 
it takes on the form of information to others. When they internalise this information, it becomes 
knowledge te them. Wisdem is a refined state of knowledge that is gained over time, and through vast 
experience. 

Some organisations deploy social media tools to promote informationsharing across geographically 
diverse project teams, two examples being Yammer (www.yammer.com) and Confluence 
(wwwatlassian.com). These tools provide secure environments that project teams can use to 
communicate and share information. 

Note: As with all the other software tools that are referred to in this book, the authors do 
not advise, recommend or support any one tool over another. You must carry out a full needs- 
analysis according to your project’s requirements prior to the adoption of any software tools. The 
examples and hyperlinks provided to resources are indicative only of what is widely available 
in the marketplace and you must form your own opinion as to their suitability and relevance to 
your project. 


16.9 SCRUM/AGILE CONSIDERATIONS 


Both Scrum and Agile promote the faceto-face approach of a colocated Scrum master and 
development team (where possible). When this occurs, the Scrum team (in general) is aware of and 
open to all of the ‘7-38-55’ modes of communication and feedback (both verbal and non-verbal). How 
the team communicates on the work assigned may be slightly more Agile in nature: instead of formal 
predictive artefacts such as the WBS, work packages and project schedules driving what has to be 
done, in the Scrum/Agile project environment, far more visual tools are utilised. For example, the 
Kanban or visual wall (refer to Figure 3.3: Example of a Trello sprint. board, in Chapter 3) is the 
primary medium around which teams communicate. 

The daily Scrum (or daily stand-up) is the Scrum equivalent of the project team meeting. Verbal 
and non-verbal messages will clearly be on show as each development team member provides their 
twominute update. 

A status board of information could be developed in relation to a more formal status report on 
the sprint, as it is progressing, and at the end of the sprint—if the software tool being used does 
not provide such a feature. An example of a sprint status report can be viewed at https://thingsi-do. 
co.uk/2018/03/06/reporting-endof-sprint-stats/ 

This is also captured in Figure 16.15. 
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It is often said in project management circles that project communications management can make or break a project. 
Crafting the right picture of the project from the get-go is important to laying successful foundations for the project. 


Moving on from stakeholder identification and analysis (discussed in Chapter 15) is the activity of identification of 
project communications. To arrive at a set of clearly defined communication protocols, the project manager must 
consider which model is the most fitting for communicating with a particular stakeholder. The project manager, 
supported by the project team and/or communications manager, defines the details of each communication. Some 
of the items considered at this point include the identification of the message which is being sent, the medium to be 
used and how frequently the communication will be sent. All this communication information will be captured in the 
Communications Matrix. 
The governance aspects of communication, such as project roles and responsibilities, review processes and 
organisational policy and procedure, are among the items that need to be captured within the Communications 
Management Plan. 
When it comes to sending a communication, the author, a reviewer and an approver will all become involved. The 
initial development (writing) of a formal communication could be carried out within the project by a project team 
member, before it is progressed through multiple reviews (technical, cultural, generational) and final approval is given. 
Once approved and sent, the communication can be recorded in the Communications Sent Register. 





During the formal communication process, the project manager will be involved in many informal communications 
with the project team: capturing know/e@ge within organisational process and systems, developing project status 
reports, and the ongoing and critical role of building and maintaining relationships with the stakeholders and the 
project team. 

A project manager needs to carefully consider their manner and the verbal and non-verbal messages they are 
sending and also how these messages are received and perceived by other stakeholders and project team members. 
The ‘7-38-55’ model and being able to understand nonverbal cues are important skills of the project manager. 

A project manager needs to be able to pick up on these non-verbal cues so they can diplomatically question 
statements and claims made by a stakeholder: for example, whether the stakeholder’s non-verbal cues contradict 
what is verbally being said. NLP, as a professional development training course, can help to foster an awareness of 
the non-verbal cues that may be used during face-to-face communication. 











Communication across project teams is likely to encompass a range of generations and learning and communication 
needs and styles. It is therefore important to consider the likely generational impact of project communications. For 
example if a Yammer social media group is set up to facilitate a discussion of project ideas, would this exclude certain 
generations from being able to participate or contribute (e.g. through lack of social media know-how, no interest in 
online discussions etc.)? 

It is important to be aware of how information is shared and communicated across the five different generations that 
will be employed in the workforce by 2020. 


Project communications can be one of the most rewarding activities of project management. When executed well, the 
benefits of good communication can be significant; it can break down cultural and age barriers, facilitate information- 
sharing, canvass new ideas, promote change and foster positive team rapport (among other aspects). However, if 
communication is not planned and executed well, a project may be at risk of failure or non-acceptance by the project's 
customers. 
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4Cs of Truth about Communication earned value management (EVM) non-verbal communications 
committee charter elevator pitch (EP) Project Management Information 
Communications Management Plan generational considerations System (PMIS) 
Communications Matrix learning styles Scrum/Agile status report 
Communications Sent Register Kanban board/visual wall sender-receiver model 
configuration management (Cl) knowledge management SMCR model (Berlo’s model) 
CPORT lines of communication Stakeholder Matrix 

cultural considerations neuro-linguistic programming (NLP) VARK 


Review questions 
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What is the significance of carrying out a detailed stakeholder analysis prior to developing the Communications Matrix? 
Define your understanding of project communications management. 


What two key models of communication were introduced in this chapter and when would one be preferred over the 
other? 


Why is it important to understand the complexities in lines of communication? 

What topics would be addressed within the project Communications Management Plan? 

What methods can be used to identify communications? 

What is the purpose of the 4Cs of Truth about Communication and CPORT when writing communications? 


What are the four directions of communication the project manager may have to consider when planning 
communications? 


What is a Project Management Information System (PMIS)? 
What are non-verbal cues, and why are they important to a project manager? 
What is VARK? Why is it important? 


Take a postcard-sized envelope, or a half-sheet of A4 paper, and create an elevator pitch (EP) for your group project. 
Share your pitch with a project team member to gain feedback and then refine the project's EP. 

Ask a colleague in the room about the status of a current project they are involved with. Ask them some easy and 
difficult questions and take note of any non-verbal cues that may reveal their inner thoughts about what is really going 
on in the project and how they feel about this. 

Use the table below to indicate/suggest what type of communication might be the most appropriate in each stated 
situation. (A response to the first situation is provided by way of an example to help get you started.) 
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A request for a change to the scope of a work package. The person who requested the change is asked 
verbally to complete a Change Request Form. 


Management (steering committee) presentation. 

Scheduling a project meeting. 

Carrying out a root-cause analysis of a problem. 

Conducting a bidder workshop. 

Notifying a project team member of poor performance (first occasion). 
Notifying a project team member of poor performance (second occasion). 
Making a change to the terms and conditions of a contract. 


Confirming a discussion regarding project reporting improvements 
with the PMO. 


4. Think about how having multiple generations in your workplace may affect the way in which communications take 
Place. What (if any) challenges have you experienced when communicating across differing generations and how 
did you resolve these challenges? Share your observations with a person in the training room who is from a different 
generation to yourself (if possible) to hear their take on this topic. 


Solutions to selected exercises are available online. 
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Learning elements 


Be able to apply the ISO standard for risk management (ISO 31000:2018) to the 
project environment, for both threat and opportunity risks. 


Understand the significance of establishing the context of risk in a project 


environment. 


Understand and apply some of the fundamental risk management tools that are 


found in a project environment. 


Respond to the challenges of monitoring and controlling risk during the execution 


of a project. 


Be able to consider the impact of risk to the project’s budget and to contingency 


reserves. 


In this chapter 


17.1 Introduction 


17.2 A risk management process 
overview 


17.3 The Risk Management Plan 


17.4 Step 1: Establishing the risk 
context 


17.5 Step 2: Risk identification 
17.6 Step 3: Risk analysis 
17.7 Further complexity in risk analysis 


17.8 Step 4: Risk evaluation 








17.9 Step 5: Risk treatment 


7.10 Opportunity risk explored 
7.11 Step 6: Contingency planning 


7.12 Common methods for 
handling risk 


7.13 Budgets, contingency and risk 
7.14 Risk monitoring and review 
7.15 Communication and consultation 


7.16 Risk management tools 





7.17 Scrum/Agile considerations 


Summary 
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17.1 INTRODUCTION 


To put ‘risk’ into perspective, a project manager needs to recognise that the essence ef preject 
management is risk management. Every technique in this book is really a risk management 
technique: each technique tries to prevent something adverse from happening its own way. Project 
selection systems try to increase the likelihood that projects will contribute to the strategic objectives 
of the organisation. Project scope documents are designed to avoid costly misunderstandings and to 
reduce scope creep from the project’s outset. As will be discovered in this chapter, managing risk 
depends on having a cemmunicated risk management precess in place. However, in the project 
team, there must be an understanding of the fact that ‘things happen’ and that risks are never static. 
It is the responsibility of the project manager to ensure there is a clear understanding that it is okay 
to talk about risk, to raise risks, and to review and change risk status. The project manager needs 
to establish an open environment where risk can be challenged and discussed as a part of daily 
conversations and where the subject is not avoided (and is therefore already on the way to becoming 
an issue). 

Risk is an integral part of project management. However, due to the varied nature of risk, it can 
be difficult to identify, despite the project manager's best efforts. According to ISO 31000:2018 Risk 
Management-Guidelines, ‘risk’ is defined as the ‘effect of uncertainty on objectives’. Therefore, it 
could be stated that. a project risk offers the potential for an event to cause a deviation from ‘the 
expected’, in either a positive or a negative manner. 

So, if a risk is defined as the potential to cause deviations in the project, what then constitutes 
an ‘issue’? PMBOK describes an issue in these terms: ‘A project risk that has occurred can also be 
considered an issue’ (PMI 2017). This implies that issues that were not initially identified in the project 
as being risks can arise. However, in general, an issue is a risk that has occurred. Establishing clear 
terminology within the project's Risk Management Plan therefore should be the first step towards 
ensuring there is shared understanding of all terms and phrases used. The consequences of some 
potential risk events, such as schedule slippages, cost overruns, equipment malfunction or changes 
in technical requirements, can be anticipated. However, other forms of risk can extend beyond most 
people's imagination; take, for example, the 2008 global financial meltdown. 

While some forms of risk can have positive consequences (such as an unexpected price reduction 
in materials), the focus of this chapter is to look at what can potentially go wrong, and the mitigating 
risk management processes we can employ to divert as much risk as possible away from the project. 
The process applied in this chapter is based heavily on the risk management standard ISO 31000:2018 
and its predecessor ISO/AS/NZS 31000:2009. This standard has been widely adopted by organisations 
within Australia (and wider afield) as the basis for the risk management policy and procedure in 
their organisations: from corporate risk, to workplace health and safety risk, to project risk. Risk 
management strategies attempt to recognise and mitigate the potential for unforeseen trouble spots to 
occur when the project is implemented. Risk management identifies as many risk events as possible 
(what can go wrong?), aims to minimise their impact (what can be done about the event before 
the project begins?), manages responses to the events that do materialise (contingency plans) and 
provides contingency funds to cover risk events that materialise. For an example of how a project 
manager must always actively ‘scan’ for risks beyond what is immediately in front of them, refer to: 
Snapshot from Practice: Land titles. 


17.2 A RISK MANAGEMENT PROCESS OVERVIEW 


Figure 17.1 graphically shows the risk management. challenge. The chances of a risk event occurring 
(e.g. an error in time estimates, cost estimates or in a technology design) are greatest during the 
Initiating and Planning stage of a project. The cost impact of a risk event in the project is less if 
the event occurs earlier, rather than later. This is because the early stages of the project represent. 
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the period when the opportunity for minimising 
the impact, or for working around a potential 
risk, exists. Conversely, as the project passes the 
halfway implementation mark, the cost of a risk High 
event occurring increases rapidly. For example, 
the risk event of a design flaw occurring after 
a prototype has been made will have a greater 
cost/time impact than if the event occurred in the 
start-up stage of the project. Clearly, identifying 
project risk events and deciding on suitable 


Risk 


responses befere the project delivers is a more 
prudent approach to take than not attempting to 
manage risk. 


Risk management requires that a preactive 
Low 


Probability of risk 
occurring 





Figure 174 Cost to fix 


Cost to fix risk 
event 


High 
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rather than a reactive approach, is taken. It is 
a preventive precess designed to ensure that Initiating 
surprises are reduced and that any negative 
consequences associated with undesirable events 


(often referred to as a threat risk) are minimised. 


Planning 


Executing 


Closing 


It also prepares the project manager to take action when a time, cost and/or technical advantage is 
possible (an opportunity risk). The successful management. of project risk affords the project 
manager better control and can significantly improve the chances of project objectives being reached 
on time, within budget, and for meeting required technical (functional) performance. 


The potential sources of project risks are unlimited. Threat risks 
can originate from many sources that may be external or internal to the 
organisation. External threat risks could include raw material price increases, 
poor market acceptance, fluctuating exchange rates and government 
regulations. Internal threat risks may include having limited office space, 
having restricted resources and having rigidly set funding. Whatever the 
source of the risk, the project manager must make every attempt to identify 
all risks, carry out actions in the project to mitigate (control) each risk and put 
in place plans (contingency) to manage the risk if it eventuates into an issue. 

To assist in the processing of risk project managers will typically adopt the 
risk management process of the parent organisation. In many cases this risk 
management process will be based on IS® 31000:2018. Figure 17.2 illustrates 


SNAPSHOT FROM PRACTICE Land titles 





Shutters teck/ChameleonsEye 


Outback community 





Australian resource (mines), energy (gas) and large-scale 


This example @emonstrates the 


importance of 


agricultural users of native title land in Western Australia 
were thrown into jeopardy after a Federal Court decision 
invalidated a large number (estimated at over 200) 
of native title land use agreements. This includes the 
debated ane still contentious A$16 billion Carmichael 
coalmine project in Queensland, Australia. 

Some communities risk losing substantial development 
funding through Indigenous land-use agreements. 


continually scanning the external environment for all 
potential risks to the project. Although a heated! topic in 
Australia, this same debate is impacting other projects 
across the globe, from Alaska to South America. 


Source: Adapted from McKenna M 2017 ‘Native title call a risk to pro jects’, 
The Australian, 8 February, https ://www.theaustralian.com.au/nationalaffairs/ 
indigenous/native title -call-a-Risk to-projects/news-story/7@e29 506ce805d 
373497f75cb35 1 8608, accessed February 2018. 
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Figure 17.2 Risk management process, 


based on IS® 316 





Communication and consultation 





Step 1 
Scope, context, 
criteria 





: Step 6 ' 


Contingency planning! 


an adapted process based on ISO 31000:2018. If such a process does not 
exist in the parent organisation, then it will be the project manager's 
responsibility to define, and subsequently communicate, such a process 
for their project. This risk management process would then be documented 
in the project’s Risk Management Plan (discussed later in this chapter). 
Establishing the basis for risk management is one of the first. 
activities the project manager has to attend to, as the risk management 
process (and the terminology used in the process) will serve to inform the 
project team and project stakeholders on all aspects of risk management, 
throughout the project life cycle. Remember, the risk management 


®18 


process is there to put. structure around the processing of risk; being ‘risk 
aware’ and making the project team risk aware is a matter of changing 
the culture so that people identify risk and are empowered to raise risks 
ina transparent and trusted culture. 
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17.3 THE RISK MANAGEMENT PLAN 


Throughout this chapter reference is made to the Risk Management 
Plan. This section outlines the typical contents of a Risk Management. 
Plan. 


E Risk centext: The context of risk needs to be captured at both the 
organisational level and at. the project level. The project manager 





== Recording and reporting = needs to consider the overarching risk context within which the 


project will operate—that is, is the context ‘riskaverse’ or ‘risk- 


Source: Adapted from |SO 31000:2018 Risk taking’ and how does this transfer into the project environment? 


Management—Guidelines 


There could be cases where the general context of risk is to be 

‘risk-averse’ but the project being worked on is out of context 
and represents a major innovation being brought to market and is inherently risky. Knowing 
the context and being able to articulate it can set expectations for the project team and greater 
stakeholder community, as provided for in Step 1 of ISO 31000:2018. 


Risk methedelegy: Refer to any corporate risk management frameworks or methodologies that 
exist (i.e. the process as illustrated in Figure 17.2) and are to be applied to management of risk 
within the project environment. Provide commentary on how risk terminology has been tailored 
to the project environment, including details of: 


— The categorisation methodology used to categorise risks. Some projects use the 1@ knowledge 
areas (PMB@K); other projects use more bespoke categories. Either way, the categorisation will 
assist the project manager and project team in reviewing categories of risks later on in the project. 


— Definitions of terminology and details of scales as appropriate, for example: 


e the probability (likelihood) of the risk occurring (e.g. 5 = certain, 4 = probable, 3 = expected, 
2 = uncertain, 1 = improbable) 

e the impact (consequence) if the risk occurred (e.g. 5 = very high, 4 = high, 3 = medi- 
um, 2 = low, 1 = unlikely) 


e the proximity of the risk to the present time. 


Risk reles and res pensibilities: Leverage the RASCI (see Chapter 14) to capture the roles and 
responsibilities associated with risk management in the project (such as issue escalation, changes 
to individual risk profiles, and improvements to the risk process). Note: This differs from the 
ewnership of risks which is captured in the Risk Register (discussed later in this chapter). 
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E Risk escalatien precess: Capture the general risk escalation process. Some of this may be 
documented in the RASCI, however, a simple flow chart may make this more accessible to the project 
team in times of need. This needs to be linked to the risk control strategy ‘escalate’, introduced into 
the sixth edition of PMBOK by the Project Management Institute (PMI 2017). 


E Risk reperting: Detail where and hew reported risk should be documented. This ensures that 
project management information is maintained to appropriate levels for reporting of risk to take 
place in an efficient and effective manner. Will for example, risk heat maps (see later in this 
chapter) be presented for discussion at the weekly status meeting? 

E Risk audits and health checks: Document details on when and by whom any risk audits are 
scheduled to be carried out. Additionally, note any planned risk workshops to revisit all risks at 
key time-points in the project schedule. 

E Lessens-learned: Review any lessons-learned from prior, similar projects regarding the 
management of risk. For negative lessons, document how these lessons relate to the project 
and what is being done in the project to ensure the lesson is not repeated. For positive lessons, 
document how the project can apply or improve the lesson. 


The Risk Management Plan is a relatively static document established during the early stages of the 
Planning stage. It is there to provide the governance for, and process and definitions of how risk is to 
be managed in the project. 


Source: © 2018 Dr Neil Pearson 


The next sections of this chapter review the steps outlined in Figure 17.2. 





17.4 STEP 1: ESTABLISHING THE RISK CONTEXT 


Organisations invariably operate within environments of risk. Understanding the external envirenment 
in which the organisation operates (and in which your project is operating) is key to knowing not only 
what potential risks may already exist, but also informs the project about. potential external risks that 
may arise. The internal risk centext defines the internal environment. within which the organisation 
seeks to achieve its objectives. Both external and internal contexts will influence the risk appetite 
of the project. For example, if the organisation is particularly riskaverse, the project manager may 
need to use strategies to treat risk to reduce the probability/impact that it will occur. In this scenario, 
effectively the project is changed to include activities to reduce the risk to as low a level as possible, or 
to remove the risk altogether. Mining companies and government entities typically take this approach 
when dealing with any potential workplace health and safety risks, or when there is a threat to the 
organisation's reputation. In some companies, approach to risk is completely the opposite; they are 
risk-takers and have a higher tolerance towards risk-taking. For example, an innovation project to 
bring a new product to the market might have a higher financial risk tolerance—it may be willing to 
fund (venture and equity funding) and manage financial risk to the project and to the organisation 
that other organisations would simply consider unacceptable. 

The project sponsor can be a useful source of information when establishing the context of risk for 
the project. The person in charge of enterprise risk management in the organisation may influence the 
risk appetite of the project. It can therefore be useful to draw both of these stakeholders into initial 
discussions about the context of risk, usually at the Initiating stage of the project. 

Some organisations use the ALARP acronym to establish the context of risk management in their 
organisation. ALARP means ‘As Low As Reasonably Practicable’, implying that the project will have 
done all that is reasonable to prevent problems and dangers. The ALARP approach requires each risk 
to be analysed separately and fellowed by the implementation of appropriate mitigation strategies. 
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17.5 STEP 2: RISK IDENTIFICATION 


Risk identification is the most critical step: if we fail to identify risk, then we cannot manage it. The 
project manager must lead the identification of risk by trying to generate a list of all possible risks that 
have the potential to affect the project. To achieve this, the project manager (typically) pulls together 
(during the Initiating stage) arisk workshop, comprising core team members and relevant stakeholders. 
The team uses brainstorming and other problem-identifying techniques to identify potential risks. 
Participants are encouraged to keep an open mind and to generate as many ideas about probable sources 
of risk as possible. Many projects have been derailed by an event that members had initially thought. 
was completely improbable and not captured. Fortunately, there are many techniques that can be used 
to identify risks. A common mistake to avoid (typically made early on in the risk identification process) 
is focusing on ‘objectives’ rather than on ‘events’ that could produce consequences. For example, team 
members may identify ‘failing to meet a schedule’ as a major risk, when what they need to focus on are the 
actual events that could cause this to happen (e.g. poor estimating, adverse weather conditions, shipping 
delays). Focusing on root causes of events will lead to better strategies to mitigate the risk later on. 


17.5.1 Risk breakdown structure and the work breakdown structure 


Many organisations use a risk breakdown structure (RBS) in conjunction with work breakdown 
structures (WBS), to help project teams identify and eventually analyse risks. Figure 17.3 provides 
a generic example of an RBS. The focus at the outset should be on risks that can affect the whele 
project, as opposed to a specific sectien of the project or network. The categories for the RBS 
can be predetermined by the project manager or, if a brainstorming approach is used, can be 
determined by the group during the brainstorming session. Typical categories of risk include 


Figure 17.3 A risk breal ructure (RBS) 
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communications, compliance, enterprise, brand, Table 17.1 An example of ‘mandatory’ risk categories 





environmental, finance, health and safety, human Sub-category 

resources, legal, physical, political, quality, social, Technical risk Technology newness 

reputational and technological—to name but a few. A Adherence to the enterprise architecture 
similar approach to that taken in the development of Compliance with ICT roadmaps/blueprints 
the WBS can be applied to the brainstorming of the RBS Technical skills in the organisation 

(ie. using Postit® notes in a workshop environment). Availability of outside technical skills 
Some organisations supply a list of mandatory risk Management risk Sponsor availability and interest 
categories that must be considered by the project Management perceptions 


Executive management team commitment 
Adherence and fit to strategy 

External risk Currency of external environment review 
Customer requirements validated? 


manager in workshopping the RBS (e.g. see Table 17.1). 
Note: The project manager should always brainstorm 
beyond any mandated categories and always keep 


an open mind. Remember, if a risk is not identified, it 7 
Review of competitors 


Changes to legislation etc. 
Commercial risk Protection of intellectual property (IP} 


cannot be assessed. Brainstorm wide and deep in order 
to ensure risks are identified, even if later assessed to 


be of low priority. Shared reward/risk with partners 

After risks have been identified at a macro level, Funding and Business Case risks 
specific (microlevel) areas can be further questioned. Change impact risk Impact to customer (internal/external) 
The WBS is an effective tool for identifying specific risks. Too many other projects impacting the business area 
A review of each work package (and task, if relevant) Impact due to poor timing with other business events 
should be undertaken and the fellowing asked: Requires organisational restructure 


Requires major skillset shift 
Æ Whatrisks are present in carrying out the activities 
within the work package and/or tasks? 


Æ Whatrisks are present when multiple activities in a work package and/or tasks are carried out at 
the same time? 


Although this can take some effort, it provides another potential perspective on risks that may 
exist at a detailed level within the project. 

Using the RBS and WBS reduces the chance of a risk event being missed. The WBS and RBS are 
complementary; it is not a case of either/or but of applying both techniques. 


17.5.2 Risk profile (list of questions) 


A risk profile is another useful tool. A risk profile is a list of questions that is used to address common 
areas of uncertainty often found on a project. These questions are predominantly developed (and 
refined) from previous, similar projects; Table 17.2 provides a partial example of such a risk profile. 


Table 17.2 Partial risk profile for a product development project 


Area of uncertainty Example question 


Technical requirements Are the requirements stable? 
Do the requirements have defined and agreed tolerances? 

Design Does the design depend on unrealistic or optimistic assumptions? 
Does the design require uncharted territory to be navigated? 

Testing Will testing equipment be available when needed? 
Will testing resources be available? 

Development Is the development process supported by a compatible set of procedures, methods and 
tools? 
Does the development process include peer reviews? 

Schedule Is the schedule dependent upon the completion of other projects? 
What other projects are dependent upon our project? 

Budget How reliable are the cost estimates? 


What is the contingency included, given the risk context and profile? 


Continued 
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Table 17.2 Centinued 


Area of uncertainty Example question 


Quality Are quality considerations built into the design? 
Are we in compliance with the customer's quality management system? 


Management Do people know who has authority for what? 
What is the steering committee accountable for? 
Work environment Do people work cooperatively across functional boundaries? 
Can company politics derail the project? 
Staffing Are staff members inexperienced, or is the company understaffed? 
Are staff members appropriately trained? 
Customer Does the customer understand what it will take to complete the project? 
Is the customer seen as a partner? 
Contractors Are there any ambiguities in contractor task definitions? 


Which contract types are to be avoided to reduce risks? 


Good risk profiles are tailored for the type of project being undertaken. For example, developing an 
information system is different from building a new car and therefore risk profiles are specific to 
the project’s subject matter. Risk profiles recognise the unique strengths and weaknesses of the firm 
and they address both technical and managerial risks. For example, the profile shown in Table 17.2 
asks questions about the design (whether the design depends upon unrealistic assumptions) and work 
environment (do people cooperate across functional boundaries?) 

Risk profiles are usually generated and maintained by staff from the project management office 
(PMO). They are updated and refined during the postproject audit (see Chapter 19). When kept 
up to date, these profiles can be a powerful resource for the project manager to have on tap in 
the risk management process. The collective experience of the firm's past projects resides in these 
questions. However, remember that risk profiles should be used in conjunction with RBS, WBS and 
other far-reaching techniques and not used as the only tool to identify risks. 


17.5.3 Lessons-learned 


Lessons-learned registers and historical records can either complement risk profiles or be used when 
formal risk profiles are not available. Project teams can investigate what happened on past, similar 
projects to identify potential risks. For example, a project manager can check the on-time performance 
of selected vendors to gauge the potential threat of any shipping delays. IT project managers can 
access best practice papers detailing other companies’ experiences of converting software systems. 
Enauiries should not be limited to recorded data. Savvy project managers also tap into the tried and 
tested wisdom of highly experienced project managers (and their peer networks). 


17.5.4 Groupthink methods 


The Delphi method is another useful tool for helping to identify risk. The Delphi method is a structured 
(initially anonymous) method that solicits information from a panel of stakeholders. Typical steps in 
using this method might resemble the fellowing: 


Step 1 Identify the group of stakeholders to be included in the task of identifying risks. 


Step 2 Senda request (e.g. an email) to each group member anonymously (as each group 
member should not know who the other members are) requesting they identify risks 
around the brief of the project you give to them. 

Step 3 Collate the responses (usually a deadline for their response is placed on the request) 
and start to pull together a structured list of the responses received. 

Step 4 Send the list back out to the group (anonymously) and again, gather responses. (The 
list should start to expand as each member of the group extrapolates on the anonymous 
responses provided by others.) 
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Repeat Steps 3 and 4 until no more content is added to the list. 
Step 5 Send the final list of identified risks to the group. 


Step 6 (Optional and not part of the formal Delphi method): Bring the group together in 
a workshop-type format to debate any differing perspectives. This is the first time 
each group member will discover who else was invited to respond, so be prepared to 
facilitate the group during discussions. 


A benefit of the Delphi method is that personalities are kept out of the risk identification process. 
Since the group is working anonymously, the focus is kept on risk identification, and not on personality 
clashes, personal plans or political agendas! 

In identifying risk, it is often the case that. only the symptoms of a risk are captured and not the 
real root cause of the risk, which after all, should be the focus of the risk analysis. Two techniques (not 
the only techniques available) that can assist the project manager to get to the root cause of a risk (or 
problem) are the ‘5 whys’ and the cause and effect (fishbone) technique—see Chapter 12. As a brief 
recap: recall that the ‘5 whys’ technique involves repeatedly asking the question ‘Why?’, with the goal 
being to peel away the layers of symptoms to reveal the core problem. Using this process, it may be 
the case that even more risks are identified. Ultimately, this process aims to get to the real risk that 
needs to be managed, rather than its symptoms. Although the process is referred to as the ‘5 whys’, in 
practice, it may be necessary to ask either fewer or more ‘Why’ questions to get to the actual cause of 
the risk. 


17.5.5 The Project Management Plan, subsidiary plans 
and other project artefacts 


The project manager also needs to review all of the other plans and project artefacts and any risks 
previously identified across any of the other knowledge areas (including scope, time, cost, quality, 
communications and information, stakeholders, procurement, integration and resources) so these 
can be logged in the Risk Register. A SWOT analysis is a useful tool for helping to understand the 
project's risk context and for facilitating the identification of hig hlevel risks. Usually carried out in the 
Initiating stage of the project life cycle, the SWOT analysis can provide a holistic perspective on risk 
for the overall project. The SWOT technique examines the project from four perspectives: strengths 
and weaknesses (from an internal perspective) and opportunities and threats (from an external 
perspective). The SWOT analysis also examines the degree to which strengths and opportunities 
offset the more harmful threats and weaknesses. 

There are inherent risks in stating assumptions (whether as part of the scope document. or 
within any of the other knowledge area management plans). The project manager must therefore 
review all assumptions made across the project, assess whether these are actually true and scrutinise 
what risks lie in making such assumptions. The same approach can be applied to constraints. 
Constraints represent a potential source of risk since, if we are immediately constraining the 
project in some dimension (e.g. funding or resource shortage), we are potentially introducing 
risk into the project. Constraints (as with assumptions) should always be reviewed from a risk 
perspective. 

The risk identification process should not be limited to only the project’s core team. Input. should 
be solicited from customers, sponsors, subcontractors, vendors and other stakeholders. Relevant 
stakeholders can be formally interviewed or included on the project’s risk management team. Not 
only can these key players potentially offer up a valuable perspective, but, by involving them in the 
risk management process, they may become more orientated towards the projects success. One 
of the keys to success around risk identification is ‘attitude’. While a ‘can-do’ attitude is essential 
during implementation, project managers have to encourage critical thinking when it comes to risk 
identification as the goal is to identify potential problems before they happen. 
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The RBS and risk profiles are useful tools for making sure no stone is left unturned. However, 
when done well, the number of identified risks can seem overwhelming and a little discouraging. 
Initial optimism might be replaced with griping and cries of ‘What. have we got ourselves into?! It is 
important that project managers set the right tone at this juncture and push forward with completing 
the risk management process so members regain confidence in themselves and in the project. It is also 
at this point that the project manager should start to develop another key artefact: the Risk Register. 

During risk identification, the project manager will typically collect information onthe fellowing items: 


E Risk ID (RID): This will be a unique reference number allocated to a particular risk (bear in mind 
that a typical project may identify hundreds of potential risks). 

E Risk name: A simple name for the risk. 

E Risk descriptien: A description of the risk that clearly describes the risk in detail. 

E Risk categery: Typically, each risk category will be the same as the categories of risk identified in 
developing the RBS. This is a useful way to later filter the Risk Register for analysis and reporting 
purposes. 

E Oppertunity/threat risk: A classification of whether the risk presents a ‘threat’ or an ‘opportunity’ 
to the project. 

E Risk seurce (date/persen/seurce ): Records ‘when, where, and by whom’ the risk was identified. 
This is a useful reference tool, because if further information/questions are raised around the risk, 
either the person who raised the risk can be contacted, or the source (a document or otherwise) 
can be referred to. 





Source: 018 Dr Neil Pearson 


Once a thorough and inclusive risk identification has been carried out, and the information 
collated in a Risk Register, the task of risk analysis has to take place. A partial example Risk Register 
is included as Table 17.3. 


Table 17.3 Risk identification: house build example 





Risk identifica 
[RiskiDð [Riskname O o — ë O] Main risk category Opportunity or threat | Date raised | Raised by | Risk owner 
RID-0001 Abnormal ground conditions discovered Foundations Risk Threat 5/12/2018/ Site Project 
when taking core samples of site. Supervisor Manager 
RID-0002 Unstable ground requires additional Foundations Risk Threat 5/12/2018/ Site Project 
ground-work prior to foundations. Supervisor Manager 
RID-0003 Inclement weather days exceed, ‘wet Foundations Risk Threat 5/12/2018/ Site Project 
days’ built into schedule. Supervisor Manager 


Source: © 2018 Dr Neil Pearson 


17.6 STEP 3: RISK ANALYSIS 


Risk analysis involves developing a clear understanding about an identified potential risk. In carrying 
out the analysis, the prebability (likelihood) and impact (consequence) of the risk occurring will be 
determined. Step 2 required a list of potential risks to be produced. Not all of these risks will deserve 
attention as some will be trivial and can be ignored; however, others will pose serious threats to the 
welfare of the project and therefore must net be ignored. Project managers have to develop methods 
for sifting through the list of risks, eliminating inconsequential or redundant ones, and stratifying 
noteworthy ones, in terms of their importance and urgency. Again, the project manager will need 
to ensure that there are clear definitions and scales in place to transparently support the terms 
‘probability’ (likelihood) and ‘impact’ (consequence). Note that: 


m Prebability refers to the probability of the event occurring. (This is otherwise known as the 
likeliheed of the risk occurring.) 
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= Impact refers to the impact of the event. (This is otherwise known as the censequence of the risk, 
if the event occurs.) 


Simply stated: risks need to be evaluated in terms of the probability of the event occurring and the 
impact if it does occur. The risk of a project manager being struck by lightning at a work site would have 
major negative impact on the project, but the probability of this happening, in reality, is so low that it 
is not worthy of further consideration. Conversely, people do change jobs, so an event such as the loss 
of key project personnel within an organisation would have not only an adverse impact but would also 
have a high probability of occurring. If it is likely to occur within a particular organisation, it may be 
wise for the organisation to be proactive and to mitigate the risk by developing incentive schemes for 
retaining specialists and/or engaging in crosstraining to reduce the impacts of turnover. It is here that 
another term will be introduced: ‘inherent’. Prior to any mitigation (control) strategies being applied to 
manage risk in the project, the project manager will review the probability of the risk eventuating and 
of its potential impact/repercussions. In Step 5, the project manager recalculates what level the risk still 
might pose after mitigation (control) strategies have been applied; this is known as the ‘residual’ risk. 

The quality and credibility of the risk analysis process requires that different levels of risk probabilities 
and impacts are defined. These definitions vary and should be tailored to the specific nature and needs 
of the project. For example, a relatively simple scale ranging from ‘very unlikely’ to ‘almost certainly’ 
may suffice for one project, whereas another project may use more precise numerical probabilities (e.g. 
0.1, 03, 0.5). Impact scales can be a bit problematic since adverse risks will affect project objectives 
differently. For example, a component failure may cause only a slight delay in the project schedule, but 
lead to a major increase in project cost. If controlling cost is a high priority, then the impact would be 
severe. If, on the other hand, time is more critical than cost, the impact would only be minor. 

Because impact ultimately needs to be assessed in terms of project priorities, different kinds of 
impact scales are used. Some scales simply use rankorder descriptors, such as ‘low’, ‘moderate’, ‘high’ 
and ‘very high’, whereas others use numeric weights (e.g. 1-10). Also, some will focus on the project 
in general, while others will focus on specific project objectives. The project manager therefore 
needs to define up-front what will distinguish a weighting of 1 from a weighting of 3; or a ‘moderate’ 
impact from a ‘severe’ impact. The documentation of risk analysis can be evidenced in various risk 
assessment forms used by different companies. A simple inherent risk analysis, using a spreadsheet, is 
included as Table 17.4 by way of an example. 

This risk analysis is the current state of the risk before any mitigation (control) strategies have 
been applied; it is often referred to as the ‘inherent risk’. In addition to evaluating the prebability 
and impact of risk events occurring, the project team can assess when the event might occur. This is 
often referred to as ‘proximity’. Again, a scale can be defined up-front. If this is applied to the same 
identified risks, it could result in Table 17.5. 


Table 17.4 Simple risk analysis: house build example 





Risk identification Inherent risk (un-mitigated risk 
Risk name Probability | Impact | Overall inherent risk (exposure) 
Probability x Impact 
RID-0001 Abnormal ground conditions discovered when taking a 4 12 
core samples of site. 
RID-0002 Unstable ground requires additional ground-work 2 4 8 
prior to foundations. 
RID-0003 Inclement weather days exceed, ‘wet days’ built into 3 3 F 
schedule. 
Probability scale Impact scale 
1 Rare 1 Insignificant 
2 Unlikely 2 Minor 
3 Possible 3 Moderate 
4 Likely 4 Major 
5 Almost certain 5 Catastrophic 


Source: @ 2018 Dr Neil Pearson 
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Table 17.5 Risk analysis (including proximity): house build example 





Risk ID 


RID-0001 Abnormal ground conditions discovered 
when taking core samples of site. 


RID-0002 Unstable ground requires additional 2 4 2 
ground-work prior to foundations. 
RID-0003 Inclement weather days exceed, ‘wet a 3 2 


days’ built into schedule. 


Probability scale Impact scale Proximity scale 

1 Rare 1 Insignificant 1 Before project handover 
2 Unlikely 2 Minor 2 Within 20 days 

3 Possible 3 Moderate 3 Within 10 days 

4 Likely 4 Major 4 Within 5 days 


5 Almost certain 5 Catastrophic 5 Immediate 





Inclusion of the proximity of the risk (i.e. how near it could occur to the current date) assists 
the project manager to be able to prioritise which risk needs to be attended to first. In this example, 
RID-0001, when multiplied by the proximity weight of 5, changes the priority of the risk and highlights 


that the risk should be attended to immediately. 


17.7 FURTHER COMPLEXITY IN RISK ANALYSIS 


The project manager can take the risk analysis further still, by extending the ‘impact. rating’. In some 
organisations, impact ratings may be assessed along a greater range of criteria. Table 17.6 provides an 


example of how impact scales could be defined, given the project objectives of cost, time, scope and quality. 
Table 17.6 demonstrates certain conditions that might be stated in impact scales regarding how a 
risk could potentially impact major project objectives (examples are provided for negative risks only). 


But how would this be integrated into the overall risk impact score? In Table 17.7 the reader can see 
that the single ‘impact’ column of the risk analysis has been replaced by the four project objective 
criteria of Table 17.6: cost, time, scope and quality. The overall risk ranking score is now calculated 
by adding the four impact criteria together and then multiplying the result by the probability: (Cost + 
Time + Scope + Quality) x Probability. This needs to be carried out for both the inherent and residual 


risk analysis (residual risk will be covered later in this section). 


There are obvious benefits in looking at the impact in this way, including the fact that the project is 
informed exactly about which area would be impacted the most if the risk were to occur. The project 
manager must be mindful of these ‘splits’ in monitoring and controlling the risk. The PMI discusses the 
‘reviewing categories’ of urgency, proximity, dormancy, manageability, controllability, detectability, 
connectivity, strategic impact and propinquity [proximity] (PMI 2017, p. 424). 


Table 17.6 An example of how impact scales could be defined 


Relative or numerical scale 
Impact rating 


1 Very low Insignificant Insignificant time Scope decrease barely 
cost increase increase noticeable 

2 Low <10% cost <5% time Minor areas of scope 
Increase increase affected 

3 Moderate 10-20% cost 5-10% time Major areas of scope 
increase increase affected 

4 High 20-40% cost 10-20% time Scope reduction 
increase increase unacceptable to sponsor 

5 Very high > 40% cost > 20% time Project result is 
increase increase rendered useless 


Source: @ 2018 Dr Neil Pearson 


[cost ime [Scope ‘uty 


Quality degradation 
barely noticeable 


Only very demanding 
applications are affected 
Quality reduction requires 
sponsor approval 

Quality reduction 
unacceptable to sponsor 


Project result is rendered 
useless 
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Table 17.7 Impact considered over multiple ‘impact’ criteria 


Risk name Probabili Impact Overall 
Cost | Time | Scope | Quality |inherent risk 


Abnormal ground conditions discovered when taking 3 4 4 $ 2 eis} 
core samples of site. 

Unstable ground requires additional groundwork prior 2 2 S 1 4 24 
to foundations. 

Inclement weather days exceed ‘wet days’ built 3 2 5 2 5 42 


into schedule. 


Some risk management software packages will allow 


Figure 17.4 Visualising risks example: probability, 


different approaches to be taken and therefore offer the benefit A A 
of being able to visualise risks on various charts. Figure 17.4 
presents an inherent risk visualisation of risks, with prebability 
plotted on the vertical axis, im pect on the horizontal axis, and 
the size of the bubble (in this case) representing preximity. 
Charts can be modified for other criteria. For example, the size 
of the bubble could represent the cost of the risk. 

Inaddition to the above qualitative risk analysis techniques, 
the project manager could take a more quantitative approach 
to the analysis of risk using techniques such as PERT, decision 
trees, and simulations (Monte Carlo). 

PERT (Program Evaluation and Review Technique) and 
PERT simulation can be used to review activity and project 
risk. PERT (and similar techniques) take a more macro 





perspective by looking at everall cost and schedule risks. The Impact 


focus is not on individual events, but rather on the probability Source: © 
of the project being completed on time and within budget. 

These methods are useful in assessing the overall risk of the project and the need for items such 
as contingency funds, additional resources and longer task durations. A PERT simulation assumes 
a statistical distribution (range between optimistic and pessimistic) for each activity duration; it 
simulates the network (perhaps over 1000 simulations) using a random number generator. The 
outcome is the relative probability (called a ‘criticality index’) of an activity becoming ‘critical’ under 





@13 Dr Neil Pearson 


the many different, possible activity durations for each activity. A PERT simulation also provides a list 
of potential critical paths, and the probabilities of each occurring. Having this information available 
can greatly facilitate the identification and assessment of schedule risk. 

Decision trees are used to assess alternative courses of action, using expected monetary value. They 
use a quantitative assessment of risk to understand all the possible outcomes for a given set of related 
project risks. An example of a decision tree analysis for a software project is provided in Figure 17.5. 
The project has three possible decisions: stay with the existing software, buy a new software package 
or develop a new software package. Each decision in turn has a tree of probable outcomes (with an 
attached probability of that outcome occurring) and the cost. (impact) should that outcome occur. The 
idea of decision tree analysis is to quantitatively analyse which decision would be best. 


Step A Define the decisions/problem. 

Step B Define the decision tree of possible outcomes. 
Step C Attach the probability of each outcome occurring. 
Step D Attach the impact of each outcome in dollars ($). 


Step E Calculate the expected monetary value of each decision (in this example, this would 
be the impact if that decision is not successful). 
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Figure 17.5 Decision tree analysis 













Stay with existing software Affect business growth 


Cost $50 000 Impact $1000 000 






Successful 
implementation 


Impact $0 





Stay with existing software Develop new software package 
Develop new software package 
Buy software package Cost $250 000 






Unsuccessful 
implementation 





Impact $1000 000 


Successful 
implementation 


Impact $0 
Buy software package 


Cost $350 000 
Unsuccessful 
implementation 


Impact $1000 000 


For example: 
Stay with the existing software: 1 x $1 000 000 = $1 000 000 
Buy software package: 0.1 x $1 000 000 = $100 000 
Develop new software package: 0.3 x $1000 000 = $300 000 
Step F Add in the costs of taking each decision. 
For example: 
Stay with the existing software: $1 000 000 + $50 000 = $1 050 000 
Buy software package: $100 000 + $350 000 = $450 000 
Develop new software package: $300 000 + $250 000 = $550 000 


Step G The DECISI@N! From the calculations above it can be seen that ‘Buy software package’ 
is the most costbalanced option, based on the probability of the risk occurring, the 
impact to the business if it occurs, and the cost of taking that decision path. 


The Monte Carlo technique is another quantitative technique. Although not frequently used in 
small and medium projects, for large, risky projects it offers a more statistical approach to assessing 
risk outcomes. The model works by taking a range of values for each risk (optimistic outcome, most 
realistic outcome and pessimistic outcome) and running hundreds or even thousands of simulations 
between these values, to obtain estimates of likely outcomes. (PMI, 2017) Note: This is an advanced 
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topic and the reader is advised to pursue specific information before using this technique—a useful 
internet resource is provided in the weblinks at the end of this chapter. 

So, let's pause to consider where the project manager will be within the risk process at this point: 
By the end of ‘Step 3: Risk analysis’ the project manager will have a solid idea of the risk profile of the 
project (potential risk); having taken the appropriate steps to analyse and ascertain the inherent risk 
score for each risk that was identified in Step 2: Risk identification. The project manager therefore 
should have a good idea by now of the overall inherent risk profile of the project. 


17.8 STEP 4: RISK EVALUATION 


Although IS® 31000:2018 separates risk evaluation from risk analysis, in practical terms, both are 
carried out simultaneously: that is, in identifying the probability and impact of a risk and evaluating 
the overall risk rating of each risk, the project manager will make decisions about which risks 
pose a higher threat to the project (or greater opportunity if the risk is an opportunity risk). IS® 
differentiates the two stages as follows: 


The purpose of risk evaluation is to assist in making decisions, based on the outcomes of the 
risk analysis, about which risks need treatment and the priority for treatment implementation. 
Risk evaluation involves comparing the level of risk found during the analysis process with 
risk criteria established when the context was considered. Based on this comparison, the need 
for treatment can be considered. (IS® 31000:2009) 


In Step 5: Risk treatment (examined below), the options available to the project manager for 
reducing the risk profile (probability and/or impact) of each identified risk are explored. This results 
in the residual risk—the risk that is subsequently monitored in the project (once all actions in the 
controls have been carried out). 

By this stage in the risk management process, the inherent risk rating for each identified risk will 
have been captured in the project’s Risk Register, including details of: 


E The probability (likelihood) rating of the risk occurring. 
m The impact (consequence) of the risk, if it occurs. 


E The overall risk rating, usually in a simple calculation (Probability x Impact), which gives an 
overall risk rating to the risk, often referred to as the inherent risk priority number (RPN). 


Æ The definitions of probability and impact and the scales and any weighting systems to be applied 
to all project risks, captured in the Risk Management Plan. 


m @ptional ‘detection difficulty’ and/or the duration of exposure criteria. 


17.9 STEP 5: RISK TREATMENT 


When a risk event has been identified and assessed, a decision must be made conceming which risk 
response is the most appropriate for the specific risk event. Responses to threat risks can be classified 
as escalate (introduced in the sixth edition of PMB@K (PMI 2017)), mitigate, avoid, transfer or accept. 
Responses to opportunity risks include escalate, exploit, share, enhance and accept. 


17.9.1 Threat risk response options 


Different. methodologies have different terminology for categories of risk responses towards differing 
threat risks. Table 17.8 illustrates the threat risk terminology used by PMB@K, PRINCE2, Praxis 
and APM. 
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Table 17.8 Threat risks: response terminology 


PMBOK PRINCE2 Praxis APM 


Escalate 
Avoid Avoid Avoid Avoid 
Transfer Transfer Transfer Transfer 
Mitigate Reduce Reduce Reduce 
Accept Accept Accept Accept 
Fallback” 
Share 


* Reactive strategy (only happens when the risk occurs and the Contingency Plan is ‘fallen back’ to) 





Table 17.9 Advised risk strategies, Some organisations will have specific categories of controls depending on 
based on inherent risk analysis what the inherent risk score was. Table 17.9 illustrates some approaches that. 
Inherent rating” | Advised threat risk m are often used to assist a project manager to apply the correct strategy, based 
| strategy to adopt on the inherent risk analysis. 
Extreme Avoid Sample threat risk response categories are now examined using the PMBOK 
High Mitigate/transfer approach. 
Medium Mitigate/transfer 
Low Accept 3 
* This table is based on plotting the inherent 17.9.2 Escalate risk 


risks on a risk heat map, 
the chapter, in Figure 17.6. 


as introduced laterin Tn the sixth edition of PMBOK (PMI 2017) an additional risk response is 
introduced—escalate’—which needs to occur when the project manager, 
team and/or sponsor agree that the threat is outside the scope/authority of the project. The escalation 
must be to a named party who will take over accountability for the risk. Parties typically involved in 
escalations include the PMO, the Program Management Office, the Portfolio Management Office, or 
the business (e.g. if the risk turns out to be a general business risk). (PMI, 2017) 
The project manager should be aware of this ‘new’ risk strategy and update any tools used (such as 
a Risk Register template) to encompass this strategy and also communicate to the project team what 
this strategy is, and how it would be applied in the project. 


17.9.3 Mitigating risk 


There are basically two strategies for mitigating risk: (1) reduce the prebability that the event will 
occur and/or (2) reduce the impact that the adverse event could potentially have on the project. Most 
risk teams focus first on reducing tke prebability of risk events occurring since there will be no need 
to consider the (potentially costly) second strategy if this approach is successful. 

Testing and prototyping are frequently used to prevent problems from surfacing later in a project. 
An example of testing could, for instance, relate to an information systems project where the project 
team is responsible for installing a new operating system in the team’s parent company. Before 
implementing the project, the team tests the new system on a smaller isolated network. By doing so, 
it discovers a variety of problems and is able to come up with solutions, prior to full implementation. 
The team may still encounter problems with the installation, but. the number and severity of problems 
is likely to be greatly reduced. 

Most often, it is beneficial to identify the root causes of an event. For example, the fear a vendor 
will be unable to supply customised components on time may be attributable to (1) poor vendor 
relationships, (2) design miscommunication or (8) lack of motivation. As a result of this analysis, 
the project manager may decide to: ‘do lunch’ with the vendor to engage with them and build trust, 
or invite the vendor to attend design meetings and restructure the contract to include incentives for 
on-time delivery. Other examples of how the probability of the occurrence of risks could be reduced 
include: (1) scheduling outdoor work to be conducted during the summer months, (2) investing in up- 
front safety training and (3) choosing highquality materials and equipment. 
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An alternative mitigation strategy is to reduce the impact ef the risk, if it occurs. For example, 
a new bridge project for a coastal port is to use an innovative, ‘continuous cement-pouring 
process’, developed by an Australian firm to save large sums of money and time. The major risk 
is that the continuous pouring process for each major section of the bridge cannot be interrupted. 
Any interruption will necessitate that the whole cement. section (hundreds of cubic yards) be torn 
down and started over (or the structural integrity of the section will be at risk). An assessment of 
‘possible risks’ centres on delivery of the cement from the cement factory. Risks identified are that 
trucks may be delayed or the factory could break down. Such risks would result in tremendous 
rework costs and delays. Risk is therefore reduced by having two additional portable cement plants 
built nearby, on different highways within 30 kilometres of the bridge project, in case the main 
factory supply is interrupted. These two portable plants carry raw materials for a whole bridge 
section and extra trucks are on immediate standby each time continuous pouring is required. Similar 
risk reduction scenarios are apparent in system and software development projects where parallel 
innovation processes are used in case one fails. 


17.9.4 Avoiding risk 


Risk avoidance involves changing the project plan to eliminate the risk or condition. Although 
it is impossible to eliminate all risk events, some specific risks may need to be avoided before you 
launch the project. For example, adopting proven technology instead of experimental technology 
can eliminate technical failure. Choosing an Australian supplier as opposed to an Indonesian supplier 
would virtually eliminate the chance that political unrest might disrupt the supply of critical materials. 


17.9.5 Transferring risk 


Passing risk to another party is common practice; however, such a transfer does not change 
the risk. Passing risk to another party almost always results in having to pay a premium for this 
exemption. Fixed-price contracts are a classic example of risk being transferred from an owner to 
a contractor. The contractor understands that their firm will have to cover the cost of any risk event 
that materialises; therefore, a monetary risk factor is added to the contract ‘bid’ price. Before electing 
to transfer the risk, the owner should decide which party is in the strongest position to be able to 
best control activities that might lead to the risk occurring. Also, serious consideration needs to be 
undertaken about whether the contractor is capable of absorbing this risk. It will be imperative to 
clearly identify and legally document details of their responsibility for absorbing the risk. 

Another, more obvious way of transferring risk is through insurance. In many instances this 
is impractical because being in a position to be able to clearly define the project risk event and its 
conditions to an insurance broker who is unfamiliar with the project can be difficult and usually 
expensive. @f course, low-probability and highimpact risk events such as ‘acts of God’ (e.g. lightning) 
are more easily definable and insurable. @ther financial instruments may be used to transfer risk, for 
example, performance bonds, warranties and guarantees. 

@n large international construction projects, like petrochemical plants and oil refineries, host 
countries often insist on contracts that enforce build-own-operate-transfer (B@®T) conditions. 
Here, the project is expected to not only build the facility, but also to take over ownership until its 
operation capacity has been proven and all debugging has occurred befere final transfer of ownership 
to the client occurs. In these cases, the host country has effectively transferred the financial risk of 
ownership until the project has been fully completed and capabilities have been proven. 


17.9.6 Accepting (retaining) risk 


In some cases, a conscious decision is made to accept the risk of an event occurring. Some risks 
are so large that it is not feasible to consider transferring or reducing the event (e.g. an earthquake 
or flood). The project owner assumes the risk because the chance of such an event occurring is 
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slim. In other cases, risks that are identified in the budget reserve can simply be absorbed if they 
materialise. The risk is retained by developing a Contingency Plan to be implemented if the risk 
materialises. In a few cases, a risk event can be ignored and a cost overrun accepted, should the 
risk event occur. 


17.9.7 Continuing the risk discussion 


The more effort that is given towards risk response befere the project begins, the better the chances 
will be for minimising project surprises. Knowing ahead of time whether the response to a risk event. 
means that it will be retained, transferred or mitigated will greatly reduce stress and uncertainty. 
Again, control is possible with this structured approach. Once a mitigation strategy has been agreed, 
it may be necessary to plan actions for reducing the overall risk rating to a residual level. This 
information should be captured in the Risk Register. The Risk Register should now track the following 
information about each identified risk: 


E Mitigatien strategy: For threat risks this would be one of mitigating, avoiding, transferring or 
accepting (retaining). 


E Mitigatien Plan: Details the actions to be carried out in the project. This could be as simple as 
noting that additional insurance is required, or may introduce additional tasks into the WBS that 
have to be resourced within the project. 


E Cest (te mitigate): What are the associated costs of carrying out the mitigation strategy? 


E Mitigatien ewner: Who in the project is responsible for ensuring that the activities outlined in the 
mitigation plan actually get carried eut and are reported back to the project manager? 


E Prebability: Once the mitigation strategy and plan have been applied, where does this leave the 
risk in relation to the probability of it occurring? 


E Impact: Once the mitigation strategy and plan have been applied, where does this leave the risk in 
relation to the impact, if it does occur? 


E Overall residual risk: The revised ‘Probability x Impact’ calculation, which gives an overall risk 
priority number (RPN) rating to the residual risk. 


— If accepting the risk, there is potentially no change to the probability and impact values. 


— If mitigating against the risk, there could potentially be a change to the probability and/or impact, 
depending on what the Mitigation Plan contained. 


— If transferring the risk, there could potentially be a change to the probability and/or impact, de- 
pending on what the Mitigation Plan contained. 


— If avoiding the risk, the project would be re-planned to ensure the risk is not present; therefore, 
there would be no residual risk rating as the risk would effectively have been removed. 


Source: ® 2018 Dr Neil Pearson 


So, what would our risk analysis now look like, given the previous example? Let’s extend the risk 
table by adding in the mitigation strategy (sometimes referred to as ‘controls’), plan and owner, and 
then review and update the values of probability and impact and the overall risk rating for what we 
now refer to as the RPN; see Table 17.10. 

Once all the actions/controls have been applied in the project, this will generate the residual RPN 
that. the project manager will want to monitor when monitoring and controlling the project during 
the Executing stage. If the ‘controls’ have not been fully actioned in the project, the project manager 
should monitor the inherent. RPN instead, as the risk has not yet been reduced to its residual value. 


Table 1710 Mitigation and residual risk assessment 





Risk identification Inherent risk (un-mitigated risk) Mitigation planning (risk response/control strategy) | Residual risk (mitigated risk) 
Risk ID Risk name Probability | Impact | Overall inherent | Strategy | Mitigation plan (control strategy) Mitigation owner | Probability | Impact | Overall residual 
risk (exposure) | risk 

RID-0001 Abnormal ground 3 4 12 Mitigate 1. Take core samples earlier in the 1. Project 1 4 4 

conditions discovered Project. Manager 

when taking core 2. Include costs in firststage 2. Finance 

samples of site. payment by customer. Director 
RID-0002 Unstable ground 2 4 8 Avoid 1. Replan the project schedule to 1. Procurement 1 4 4 

requires additional include additional steps in the Manager 

ground-work prior to land procurement strategy, so 

foundations. land is not purchased that has a 

high cost of pre-work. 

RID-0003 Inclement weather days 3 3 9 Accept 2 3 9 


exceed, ‘wet days’ built 
into schedule. 


Probability scale Impact scale 

1 Rare 1 Insignificant 
2 Unlikely 2 Minor 

3 Possible 3 Moderate 

4 Likely 4 Major 

5 Almost certain 5 Catastrophic 


Source: © 2018 Dr Neil Pearson 
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17.10 OPPORTUNITY RISK EXPLORED 


So far, this chapter has focused on threat risks (negative) to the project (i.e. what can go wrong on a 
project). There is a flip side: there can be positive risks on a project that, when well-managed, have the 
potential to enhance project outcomes. This is commonly referred to as opportunity (positive) risk. 
An opportunity is an event that can have a positive impact on project objectives. For example, unusually 
favourable weather can accelerate construction work, or a drop in fuel prices may create savings that 
could be used to add value to a project. Essentially, the same process that is used to manage threat 
risks is applied to opportunity risks. ®pportunities are identified, assessed in terms of likelihood and 
impact, responses are determined, and contingency plans can even be established to take advantage 
of the opportunity if it occurs. The major exception between managing negative risks and opportunity 
risks is in the response approach taken, as ‘treatment’ strategies are different for opportunity risks. 
Table 17.11 illustrates opportunity risk terminology used by PMB@K, PRINCE2, Praxis and the APM. 

As outlined in Table 17.11, when dealing with an opportunity risk, the project manager has to 
consider how potential benefits from the opportunity risk are to be managed and enhanced within the 
project. To help unpack this, let’s take a look at an example of an opportunity risk presented in a Risk 
Register (see Table 17.12). 

The inverse is happening to the overall risk ranking of the opportunity risk. This is because we 
want to enhance the opportunity and reap rewards greater than were planned, when it does occur. 


ane Fi Opportunity risks, response E Exploit: This tactic seeks to eliminate the uncertainty associated 
cone ogy with an opportunity to ensure that it definitely happens. Examples 


BMBC RS ERNE? [Praxis [APM | include assigning your best personnel to a critical burst activity 


Escalate = = = to reduce ‘time to completion’ or revising a design to enable a 

Banat EIA SG o E component to be purchased, rather than developed internally. 

Share Share Share Share 

Sree EE Enhance Enhance ™ Share: This strategy involves allocating some or all of the ownership 

Accept of an opportunity to another party who is best able to capture it for 
Reject (i.e. not to exploit/ Reject Reject the benefit of the project. Examples include establishing continuous 
enhance/share the risk) improvement incentives for external contractors, or joint ventures. 


Table 17.12 Opportunity assessment 





Risk identification Inherent risk (un-mitigated risk) Mitigation planning (risk response/ | Residual risk (mitigated risk) 
control strategy) 
Risk ID | Riskname Probability | Impact | Overall Strategy Mitigation Mitigation | Probability | Impact | Overall 
inherent risk plan (control residual risk 
(exposure) strategy) 
RID0004 Attaining a high il 4 4 Enhance Undertake a Project 4 5 20 
Nationwide construction Manager 
House Energy review and 
Rating Scheme build to 
{NatHERS) NatHERS 
and National and NABERS 
Australian Built standards 
Environment highest rating. 
Rating System 
({NABERS), 
enables a 


premium selling 
Price to ‘green’ 
customers. 


Probability scale impact scale 


1 Remote 1 Minor 

2 Low 2 Moderate 

3 Medium 3 Major 

4 Probable 4 Substantial 

5 Certain 5 Transformative 


Source: © 2018 Dr Neil Pearson 


CHAPTER 17 PROJECT RISK MANAGEMENT 


E Enhance: ‘Enhance’ is the opposite of mitigation, in that action is taken to increase the probability 
and/or the positive impact of an opportunity. Examples include choosing site location based 
on favourable weather patterns or choosing raw materials that are likely to decline in price (so 
savings are made). 


m Accept: ‘Accepting’ an opportunity means being willing to take advantage of it if it occurs, but not 
taking action to pursue it. 


While it is only natural to focus on threat risks, it is sound practice to engage in active eppertunity 
risk management as well. The process around how to analyse an opportunity risk is similar to that of 
a threat risk; with some adjustments in how the terminology is applied. Consider the fellowing: 


Æ Opportunity prebability: How likely is the opportunity to happen? (We want it to happen given 
that it is an opportunity.) 


Æ Opportunity impact: How helpful would it be if it did happen? (We want to exaggerate its impact 
so we can reap greater rewards.) 


With risk response or ‘enhancement’ (not mitigation) strategies, we are trying to (a) make the 
opportunity happen and (b) make it better: that is, we want to exploit and maximise opportunities so 
the resulting (residual) probability and impact is higher (i.e. we want to increase the probability of it 
occurring, and enhance the impact). We would therefore put in place an Enhancement (not mitigation) 
Action Plan and implement the actions. Refer to Table 17.12. 

Remember, we wish to minimise threats and leverage opportunities. 


17.11 STEP 6: CONTINGENCY PLANNING 


A Contingency Plan is an alternative plan that will be used if a possible foreseen risk event becomes 
a reality (i.e. an issue). The Contingency Plan represents actions that will occur when the risk actually 
occurs. A key distinction between a risk response (mitigation strategy) and a Contingency Plan is 
that a response is part of the actual Implementation Plan, and action is taken before the risk can 
materialise, while a Contingency Plan is not part of the initial Implementation Plan, and only goes into 
effect after the risk is recognised and becomes an issue. 

Like all plans, the Contingency Plan answers the questions of ‘what, where, when and how much’ 
action will take place. The absence of a Contingency Plan when a risk event occurs can cause a manager 
to delay or postpone the decision to implement a remedy. This postponement can lead to panic and a 
situation in which the first remedy suggested is latched onto. Such ‘after-the-event’ decision-making, 
made under pressure, can be potentially dangerous and costly. Contingency planning evaluates 
alternative remedies for possible foreseeable events befere the risk event occurs and so the best plan 
can be selected from alternatives. Such early contingency planning facilitates a smooth transition to 
the remedy, or ‘work-around’ plan. The availability of a Contingency Plan can significantly increase 
the chances for project success. Conditions for activating the implementation (sometimes referred to 
as triggers) of the Contingency Plan should be decided and clearly documented in the Risk Register, 
against each risk, as required. For highpriority risks, where there is a residual high probability and/or 
impact of the risk becoming an issue and having to be managed, the plan should include a cost estimate. 
All parties that will be affected should agree to the Contingency Plan and have the authority to make 
commitments. Because the implementation of a Contingency Plan will embody some disruption in the 
sequence of work, all contingency plans need to be communicated to team members so that surprise 
and resistance are minimised. Table 17.13 illustrates a Risk Contingency Plan. 

Taking the Risk Register to its ‘final stage’ in this process requires the fellowing information to 
be noted against each risk for which it was necessary to have a Contingency Plan in place. (Note: 
Typically this will be risks that have a high-probability and highimpact rating.) 


Table 1713 Risk Contingency Plan 


Risk identification Inherent risk (unm itigated risk) Mitigation planning (risk Residual risk (mitigated risk) Contingency Planning 
__fesponse/control strategy) 


RiskID |Riskname | Probability | ‘Impact Overall Strategy | Mitigation | Mitigation | Probability impact O etall. Contingency | Trigger Contingency | Cost of 


inherent plan owner (event) action (event) plan carrying 
risk (control plan owner out the 
(exposure) strategy) contingency 
plan 











RID-0003 Inclement 3 3 9 Accept 3 a p S Employ Wet Project Manager AU$500/ 
weather ‘contractrate’ weather day/ 
days labourers. days contractor 
exceed, Crash and fast exceeds 
‘wet days’ track, project ‘industry 
built into schedule to standard’ 
schedule. allow parallel buffer 

activitieswith included 
additional in project 
resources. schedule. 

RID-0017 Concrete 3 5 15 Accept a 5 15 Standby Pump Site Supervisor ‘AU$3000/ 
pump arrangements breakdown, half-day 
machine with local hire not 
breakdown. company put serviceable 

in place. within 
15 minutes. 





Source: © 2018 Dr Neil Pearson 
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E Centingency (event) Actien Plan: If the risk becomes an issue, what is the planned sequence of 
events to be taken to manage the situation? (At times, these plans can be extensive and may have 
to be documented elsewhere, with a reference to the plan captured in the Risk Register.) 


Trigger: Details of what triggering event causes the plan to be invoked. 


E Centingency (event) plan ewner: Who is going to take charge of managing the Contingency Plan, 
once the trigger event has occurred? 


E Cest ef centingency: What are the potential costs to the project in invoking the Contingency Plan? 


Within the inclusion of contingency planning (not formally a step within ISO 31000:2018), the 
process of identifying, analysing, evaluating and treatment of risks is now complete. The majority 
of risk planning is carried out during the Planning stage of the project. However, when new risks are 
identified during the progression of the project, or when the status of risks changes, the same process 
has to be repeated. 


17.12 COMMON METHODS FOR HANDLING RISK 


Some of the most commonly encountered methods used for handling risk are discussed in the fellowing 
sections. Although the choice of approach may vary from project to project, there are some prevailing 
common themes that a project manager should be aware of. 


17.12.1 Technical risks 


Technical risks are problematic as they can cause a project to be shut down if the system or process 
does not work. Contingency (or backup) plans are made for unforeseen possibilities. For example, 
Carrier Transicold is involved in developing a new Phoenix refrigeration unit. for truck+trailer 
applications. This new unit is to use rounded panels made of bonded metals, which is new technology 
for Transicold. One of its competitors has previously unsuccessfully tried to incorporate similar 
bonded metals in its products. The project team is eager to make the new technology work, but it isn’t 
until the very end of the project that it is able to get the new adhesives to bond adequately to complete 
the project. Throughout the project, the team maintains a welded-panel fabrication approach just 
in case the ‘bonding’ technique is unsuccessful. If this contingency approach is needed, it will have 
increased production costs, but the project would still be completed on time. 

In addition to having backup strategies in place, a project manager also needs to develop methods 
to be able to quickly assess whether technical uncertainties can be resolved. By isolating and testing 
key technical questions early on in a project, project feasibility can be quickly be determined and any 
necessary adjustments made (such as rewerking the process or insome cases, clesing dewn the project). 


17.12.2 Schedule risks 


Some organisations will defer dealing with the threat of a project coming in late until this situation 
surfaces. Contingency funds are set aside to expedite or ‘crash’ the project to get it back on track. 
Crashing, or reducing, the project's duration is accomplished by shortening (compressing) one or 
more activities on the critical path. However, this approach brings additional costs and risks. Some 
contingency plans can avoid costly procedures. For example, schedules can be altered by working 
activities in parallel, or by using startto-start lag relationships. Also, using the best people on high- 
risk tasks may relieve, or lessen, the chance of some risk events occurring. This approach could 
potentially be combined with fast-tracking the schedule—see Chapter 9. 


17.12.3 Schedule risks and time buffers 


Just as contingency funds are established to absorb unplanned costs, managers can use time buffers 
to cushion potential delays in the project. Like contingency funds, the amount of time buffered will be 
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dependent upon the inherent uncertainty of the project (i.e. the more uncertain the project, the more 
time should be reserved for the schedule). The strategy is to assign extra time at critical moments in 
the project. For example, buffers are added to: 


activities with severe risks 
merge activities that are prone to delays due to one or more preceding activities being late 


E 
E 
E non-critical activities, to reduce the likelihood that they will create another critical path 
E 


activities that require scarce resources, to ensure the resources are available when needed. 


In the face of overall schedule uncertainty, time buffers are sometimes added to the end of the 
project. For example, a 300day project may have a 30-day project buffer. While the extra 30 days 
would not appear on the schedule, they would be available if needed. Similar to management reserves, 
time buffers typically require the authorisation of top-level management. 


17.12.4 Cost risks 


For projects that have a long duration, some contingency will need to be built in to accommodate 
price changes (which are usually upward). An important point to remember when reviewing pricing 
is to avoid the potential trap of only using one lump sum to cover price risks. For example, if inflation 
has been running at about 3 per cent, some managers will add 3 per cent for all resources used in the 
project. This lumpsum approach does not address exactly where price protection is needed and fails 
to provide opportunities for tracking and control. On cost-sensitive projects, price risks should be 
evaluated item by item. Some purchases and contracts will not change over the life of the project. 
Those that may change should be identified, and estimates should be made of the potential magnitude 
of those anticipated changes. This approach ensures control of contingency funds as the project is 
implemented. 


17.12.5 Funding risks 


What if the funding for the project is cut by 25 per cent, or completion projections indicate that costs 
will greatly exceed available funds? What are the chances of the project being cancelled before 
completion? Seasoned project managers recognise that a complete risk assessment must include an 
evaluation of funding supply. This is especially true for publicly funded projects. Just as government 
projects are subject to changes in strategy (and political appetites) business firms also frequently 
undergo changes in their priorities. They may also face staff changes in top management personnel 
and the ‘pet’ projects of a new CEO may replace the pet projects of the business's former CEO. 
Resources may become tight and one sure way to fund new projects is to cancel existing projects. 
Severe budget cuts or lack of adequate funding can have a devastating effect on a project. Typically, 
when such a fate occurs, it becomes necessary to scale back the scope of an existing project to 
‘what is possible’. (‘Allornothing projects’ are ripe targets for budget-cutters.) This was the case for 
the Comanche helicopter after the decision was made to move away from manned reconnaissance 
aircraft. The ‘chunkability’ of an existing project can act as an advantage. For example, a motorway 
resurfacing project may not get fully completed but the project will still have added value for each 
mile that has been fully completed and left safer. 

On a much smaller scale, some funding risks may exist for more ‘pedestrian’ projects. For example, 
a building contractor may find that due to a sudden downturn in the stock market, a private individual 
can no longer afford to have him build their dream house for them on land the contractor owns or an ICT 
consulting firm may be left emptyhanded when a major client files for bankruptcy. Inthe former case, the 
contractor may have, as a contingency, the option of building and selling the house on the open market; 
unfortunately, the ICT consulting firm would likely have to join a (potentially) long line of creditors. 
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17.15 BUDGETS, CONTINGENCY AND RISK 


Work carried out in identifying and assessing risk can be utilised to make financial decisions about 
the mitigation of risks and can inform the level of contingency that must be retained in the project 
reserves. This information can ultimately also indicate how much the management reserve is likely to 
be affected by the overall risk in the project (these reserve types were discussed in Chapter 10). The 
PMI describes risks as ‘known unknowns’ because although the risk has been identified (itis ‘known), 
it is not known (in reality) if the risk will occur (‘unknowns’). 


Decision: Inherent risk versus the cost to mitigate the risk. 


The project manager needs to consider what the cost to the project would be if the risk did 
occur (in its unmitigated state) compared to what the cost would be to put mitigation strategies 
(controls) in place. If the cost of the controls is greater than the cost of the risk occurring, then the 
project manager might decide not to implement the controls. For example, there is a risk that 
the project manager will leave the project. This inherent risk is analysed and the cost, if the project 
manager leaves, is estimated to be $5000. The mitigation strategy is to employ a trainee project 
manager to shadow the experienced project manager, at a cost of $15 000 to the project. Based 
on these numbers alone (not considering any other associated risks), the project manager makes 
a financial decision (in conjunction with the project sponsor), not to employ a shadow project 
manager and to instead ‘run the risk’ that they (the project manager) may not be present for the 
entire project. This is an example of where costs inform decision-making (i.e. the cost of the risk 
occurring inits unmitigated (controlled) state is less than the cost to mitigate, therefore the decision 
is made net to mitigate). 


Higher (RPN) residual risks 


If a risk (regardless of what controls have been applied) remains at a high level, there is a likelihood 
that contingency plans ceuld be enacted. The project manager therefore needs to consider the 
costs of these contingency plans occurring. Two options should be considered: the tetal cest of 
the contingency plans, or a weighted cest. In Table 17.14, the project manager could (for all risks 
where there is a Contingency Plan) take the raw sum of the ‘contingency plan costs’ forward to the 
sponsor for inclusion in the management reserve or take the sum of the ‘weighted costs’ forward to 
the sponsor for inclusion in the management reserve. Refer to Table 17.14 for an example of how to 
calculate the expected monetary value (EMV) of a single risk. 

Table 17.14 presents a single risk. If the activity were carried out across all risks in the Risk 
Register, the project manager might incur significant cost to the project. If this is the case, the resulting 
total figure should be considered when calculating the ‘project's contingency’ and/or the ‘management 
contingency’ for the project. (Refer to Chapter 10.) 


Table 17.14 Expected monetary value (EMV) of a single risk 


ae Probability | Contingency Plan Contingency Plan cost | Weighted cost 


Concrete pump Standby arrangements with $3000 .6* x $3000 = $1800 
machine breakdown local hire company put in place. 
“Probability scale 


1 Remote < 20% 

2 Low >20% < 40% 

3 Medium >40% < 60% 
4 Probable >60% < 80% 
5 Certain >80 < 100% 
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17.14 RISK MONITORING AND REVIEW 


Referring back to Figure 17.3, the reader will have noticed a ‘monitor and review component to the 
process. Typically, the results of the six steps to risk management are summarised in the Risk Register. As 
indicated within each step, the Risk Register details all identified risks, including descriptions, categories, 
the probability of their occurrence, impacts, responses, contingency plans, owners and current status. 
The Risk Register is the backbone of risk monitoring and review. Risk monitoring and control involves: 


m Ensuring the risk mitigation strategies (controls) are being actioned by the assigned project team 
member. 


m Monitoring contingency triggering events and initiating contingency plans as required. 


m Escalating risks that move out of project control, per the newly introduced ‘escalate’ risk 
response category. 


m Watching for new risks and logging these into the Risk Register for subsequent. analysis. 


@ Monitoring existing risks for changes in conditions that will affect the profile of the risk. 


These activities are illustrated Figure 17.6. 
Arisk heat map, as illustrated in Figure 17.6, is a very popular medium for helping to visualise and 
facilitate the reporting of risk status. In this case, the diagram has two heat. maps: 


Em The heat map on the left-hand side maps out key risks for threat risks (and is usually presented 
on a green through red colour scale). The colour red would indicate (in ‘monitoring and 
controlling’ risks) that the risk has a high potential to breach, and therefore turn into an 
issue; at. which point its contingency plan would be instigated. It may be that the project manager 
is, at this time, already carrying out actions to further reduce the probability/impact of this risk, 
if it is in such a position on the Risk Register. Generally, risks should be moving from top right 
(red) to the bottom left (green) as the project manager seeks to reduce the threat of the risk. 


@ The heat map on the righthand side represents eppertunity risks. The project manager would want 
to increase the probability of the risk occurring and would be looking to extend its impact if it does 
occur. Risks would therefore be moving from the bottom right to the top left of the grid. 


The visual heat map (and its associated risk summary) would form a component of a typical 
project status report, as risks are always reported on. Any changes to risks that impact on the project 
will, of course, be subject to the project’s change request process (previously discussed in Chapter 7) 
to be able to access either the ‘project contingency’ or the ‘management. contingency’. 

Project managers need to monitor risks just as they track project progress. Risk assessment 
and updating has to be part of every status meeting and project progress report. The project team 
has to be on constant alert for new, unforeseen risks. Management needs to be sensitive to the fact 
that others may not be forthright in acknowledging new risks and problems. Admitting that there 
might be a bug ina design code, or that different. components are not compatible, may be seen to 
reflect poorly on an individual's performance. If the prevailing organisational culture is one where 
mistakes are punished severely, then it is only human that people will want to protect themselves 
from admonishment. Similarly, if bad news is greeted harshly and there is a propensity to ‘kill the 
messenger’, participants will naturally be reluctant to speak freely. The tendency to suppress bad 
news is compounded when individual responsibility is vague and the project team is under extreme 
pressure from top-level management to get the project done quickly. 

Project managers need to establish an environment in which participants feel comfortable that 
they can raise concerns and admit mistakes. The norm should be that revealing mistakes is acceptable, 
whereas hiding mistakes is intolerable. Problems should be embraced, not supressed. Participants 
should be encouraged to identify problems and new risks. The key to this is the project manager's 
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own attitude and actions, as they must actively demonstrate a positive, supportive attitude. On large, 
complex projects, it may be prudent to repeat the risk identification/assessment exercise with fresh 
information. Risk profiles should be reviewed to test if the original responses still hold true. Relevant 
stakeholders should be brought into the discussion and the Risk Register will need to be updated. While 
this may not be practical on an ongoing basis, project managers should touch base with stakeholders 
ona regular basis or hold special stakeholder meetings to review the status of risks on the project. 

A second tactic for controlling the cost of risks is to document responsibility. This can be 
problematic in projects involving multiple organisations and contractors. Responsibility for risk is 
frequently passed on to others with a dismissive comment along the lines of: ‘That's not my concern’. 
This mentality is dangerous. Each identified risk should be assigned (or shared) by mutual agreement. 
of the owner, the project manager and the contractor, or person having line responsibility for the work 
package or iteration of the project. Risk costs, when identified as part of risk planning and activities, 
have to take place in the project and therefore should be included in the project budget. However, 
when a risk eventuates and becomes an issue, the project manager may have to apply to the steering 
committee and/or sponsor to draw on project contingency funds. Having line personnel participate 
in the process focuses attention on the budget reserve, control of its rate of usage, and early warning 
about potential risk events. If risk management is not formalised, responsibility and responses to risk 
will be ignored—'It’s not my area...’. 

The project manager needs to be prepared for independent risk audits. These may be carried out. 
as routine health checks by the PMO or by the organisation’s corporate risk department (a schedule 
of these could be captured in the Risk Management Plan). However, in some instances, these may be 
externally initiated by boards or by governing bodies and therefore the project manager might not 
necessarily know about them in advance. Note: If your organisation has a gateway review precess 
(such as the OGC Gateway™ Review process), risk will be examined in detail at these reviews. 


17.14.1 Risk closure 


Remember, once the risk event has passed, the risk should be closed down and the Risk Register 
updated appropriately. It is important to remove unnecessary noise, so that focus is retained on 
current risks. The bottom line is that project managers (and team members) need to be vigilant and 
constantly on the lookout for potential risks so any new land mines that could potentially derail a 
project can be expediently defused. Risk assessment has to be part of the recurring agenda of status 
meetings, and when new risks emerge, these need to be analysed and incorporated into the risk 
management process. 


17.15 COMMUNICATION AND CONSULTATION 


Referring back to Figure 17.2, you will notice a ‘communication and consultation’ component. to 
the process. This component is to remind the project manager that risk planning is not, and should 
not be, carried out in isolation. Internal and external stakeholders bring with them many differing 
backgrounds, perspectives and experiences. In considering risk, it is especially important that different. 
backgrounds, perspectives and experiences are included in activities, so that risk can be identified 
and mitigated. By creating a consultative approach to risk management, the project manager can: 


@ Establish the risk context, both in regards to the external environment and the internal 
(organisational) environment. 


m Draw in stakeholders to ensure their interests (from a risk perspective) are understood and captured. 


Æ Bring together people with different or complementary backgrounds, to assist in a more complete 
risk analysis of the project. 


@ Seek input about how to deal with the risk from the people involved in the analysis. 
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Consultation is key to understanding not only the risks, but also the process being applied to the 
management of risks in the project. From a communication perspective, the details of risks should 
appear in ell formal project management status reports produced from the project. Risks will be an 
agenda item at team meetings and steering committee meetings. 


17.16 RISK MANAGEMENT TOOLS 


This chapter has leveraged Microsoft Excel® for capturing, tracking and monitoring risk examples. 
For projects where a lot of risk has to be managed, project managers may like to look to the wide 
range of tools that are available in the marketplace. Some examples are provided in Table 17.15. 
(Note: While this list is provided as an example, the authors categorically do not endorse any of the 
tools listed and this list cannot be relied upon to be current, complete or accurate. You must form your 
own opinion when selecting any product.) 


Table 7.15 Risk management tools 


Tool Weblink 


Oracle Crystal Ball https://www.oracle.com/applications/crystalball/index.html 
Risksoft www.Risk-soft.com 

Cura www.curasoftware.com 

Active Risk www.sword-activeRisk.com 

@Risk www.palisade.com/Risk/ 

RiskyProject http://intaver.com 


17.17 SCRUM/AGILE CONSIDERATIONS 


Risk is implied and almost ‘bundled’ into the Scrum methodology. For example, when using MoSCoW 
to prioritise product backlog items, the product owner will consider the risk implications (to the 
business) of implementing, or of net implementing, the particular user story. Similarly, when the 
development team estimates story points at the sprint planning meeting, they need to think about, and 
include, considerations of risk into the estimating process. 


To put project risk into perspective, the project manager needs to recognise that the essence of project 
management is risk management. Every technique discussed in this text is really a risk management 
technique: each tries to prevent something adverse from happening its own way. Project selection 
systems try to increase the likelihood that projects will contribute to the strategic objectives of the 

firm. Project scope documents, among other things, are designed to avoid costly misunderstandings 
and to reduce scope creep, from the project outset. This chapter has covered the following: 


m Project managers need to understand the context for risk in the industry, the environment, the 
organisation and the project, so expectations around risks and how these are managed can be 
established with the project sponsor and other stakeholders. 

m Risk breakdown structures (RBS) reduce the probability that some vital part of the project will be omitted or that 
budget estimates are unrealistic. Team building reduces the probability of dysfunctional conflict and breakdowns 
in coordination. All of the techniques try to increase stakeholder satisfaction and increase the chances of project 
SUCCESS. 

m From this perspective, project managers engage in risk management activities to compensate for 

the uncertainty inherent in project management and the fact that things never go according to plan. 

Risk management is proactive, not reactive. It reduces the number of surprises and leads to a better 
understanding of the most likely outcomes of threat (negative) events. 
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m Although many managers believe that in the final analysis, risk assessment and contingency will depend upon 
subjective judgement, some standard method for identifying, assessing and responding to risks should be included 
in all projects. The very process of identifying project risks forces a level of discipline at all levels of project 
management and stands to improve project performance. 

m Contingency plans increase the chance that the project can be completed on time and within budget. Contingency 
plans can be simple workarounds or elaborately detailed plans. Responsibility for risks should be clearly identified 
and documented. It is desirable and prudent to keep a reserve to hedge against project risks. Budget reserves 
are linked to the WBS and should be communicated to the project team. Control of management reserves should 
remain with the owner, project manager and line person responsible. Use of contingency reserves should be closely 
monitored, controlled and reviewed throughout the project life cycle. 


Experience clearly indicates that using a formal, structured process to handle possible foreseen and unforeseen 
project risk events minimises surprises, costs, delays, stress and misunderstandings. Risk managementis an iterative 
process that occurs throughout the life cycle of the project. When risk events occur, or changes are necessary, using 
an effective change control process to quickly approve and record changes/variations will facilitate performance 
being measured against the schedule and budget. Ultimately, successful risk management requires a culture in which 
project threats are embraced, not denied, and problems are identified, not hidden. 





Ten golden rules of project risk management 

m Rule 1: Make risk management part of your project. The first rule is essential to the success of project risk 
management. If you don’t truly embed risk management into your project, you cannot reap the full benefits of this 
approach. 

m Rule 2: Identify risks early in your project. The first step in project risk management is to identify the risks that are 
present in your project. This requires an open mindset that focuses on future scenarios that may occur. 

m Rule 3: Communicate about risks. Failed projects show that project managers were frequently unaware of the big 
hammer that was about to hit them. The frightening finding was that frequently someone in the project organisation 
actually did see the hammer, but didn’t inform the project manager of its existence. 

m Rule 4: Consider both threats and opportunities. Project risks have a negative connotation: they are the bad 
guys that can harm your project. However, modern risk approaches also focus on positive risks: the project 
opportunities. 

m Rule 5: Clarify ownership issues. Some project managers think they have finished once they have created a list of risks. 
However, this is only a starting point. The next step is to clarify who is responsible for what risk. 

m Rule 6: Prioritise risks. A project manager once told me, ‘I treat all risks equally’. This makes project life really simple. 
However, it doesn’t deliver the best results possible. Some risks have a higher impact than others. 

m Rule 7: Analyse risks. Understanding the nature of a risk is a precondition for a good response, therefore take 
some time to have a closer look at individual risks and don’t jump to conclusions without knowing what a risk 
is about. 

m Rule 8: Plan and implement risk responses. Implementing a risk response is the activity that actually adds value to 
your project. You prevent a threat occurring or minimise negative effects. Execution is key here. The other rules 
have helped you to map, prioritise and understand risks. This will help you to make a sound risk response plan that 
focuses on the big wins. 

m ule 9: Register project risks. This rule is about bookkeeping: Maintaining a risk log enables you to view progress 
and make sure you won't forget a risk or two. It is also a perfect communication tool that informs your team members 
and stakeholders about what is going on (Rule 3). 

m Rule 10: Track risks and associated tasks. The Risk Register you have created as a result of Rule 9 will help you to 
track risks and their associated tasks. Tracking tasks is a day-to-day job for the project manager. Integrating risk tasks 
into that daily routine is the easiest solution. 





Source: Adapted from Jutte B n.d., 10 Gel@en Rules ef Project Risk Management, www.pro jectsmart.co.uk/ 10.golden-tules-of prejectRiskmanagement. 
html, accessed 23 October 2012. 


www.Risk-doctor.com 
https://www.pmi.org/pmbok-guide-standards/framework/practice-standard-project-Risk-management 
https://www.theirm.org 

https://www.iso.org/obp/ui/#iso:std:iso:3 1000:ed-2:v1:en 
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https://infostore.saiglobal.com/en-gb/Standards/ISO-3 1000-2018-1961810/?gclid=CjOKCQiA0V7 
VBRDtARIsSAHWoO-JRqMWczzkSoOKN4 
QRqF74XqGdHIKMOn_v9Q5FIN7t_MoTpNH8e8 
V4aAsXMEALw_wcB 

https://www.oracle.com/applications/crystalbalVindex.html 

www.Risk-soft.com 

www.curasoftware.com 

www.sword-activeRisk.com 

www.palisade.com/Risk/ 

http://intaver.com 

https://www.riskamp.com/files/Risk AMP%20-%20Monte%20Carlo%20Simulation.pdf 

https://www.iso.org/standard/65694.html 

https://www.iso.org/standard/431 70.html 


‘5 whys’ mitigation strategy (risk response) tisk identification 

ALARP Monte Carlo technique Risk Management Plan 

assumptions ‘noise’ Risk Matrix 

constraints opportunity risk (positive risk) tisk monitoring and review 

contingency plans PERT risk priority number (RPN) 

cost of contingency PERT simulation risk profile 

decision tree analysis probability (likelihood) Risk Register 

Delphi method tisk analysis Risk Severity Matrix 

escalate risk appetite risk workshop 

expected monetary value (EMV) tisk breakdown structure (RBS) root cause 

impact (consequence) tisk closure root-cause analysis (RCA) 

issue tisk context SWOT analysis 

ISO 31000:2018 Risk tisk evaluation threat risk (negative risk) 
Management-Guidelines risk heat map trigger 


Review questions 


4. Project risks can/cannot be eliminated even if the project is carefully planned? Explain. 


2. The chances of risk events occurring and their respective costs increasing change over the project life cycle. What is 
the significance of this phenomenon to a project manager? 


What is the difference between ‘avoiding’ a risk and ‘accepting’ a risk? 

What is the difference between ‘mitigating a risk’ and ‘contingency planning’? 

Explain the difference between ‘opportunity’ risk and ‘threat’ risk. 

Why are the WBS and RBS complementary in identifying risk? 

What are the likely outcomes if a change control process is not used? Why? 

What are the parallels between a standard such as ISO 31000:2018 and the Risk Management Plan? 
What does the control strategy ‘escalate’ mean to the project manager? 


SO CO ed SU vin a 0 


= 


For a project you are currently involved in: identify and assess major and minor risks that are inherent to the project. Decide 
ona mitigation strategy, and the residual risk profile. Develop a contingency plan for two to four identified risks. Estimate 
costs. Assign contingency reserves. How much reserve would your team estimate for the whole project? Justify your 
choices and estimates. 
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2. You have been assigned to a project risk team comprising five members. Because this is the first time your organisation 
has formally set up a risk team for a project, it is hoped that your team will develop a process that can be used on all 
future projects. Your first team meeting is next Monday morning. Each team member has been asked to prepare for the 
meeting by developing, in as much detail as possible, an outline that describes how you believe the team should proceed 
in handling project risks. Each team member will hand out their proposed outline at the beginning of the meeting. Your 
outline should include, but not be limited to, the following information: 


(a) team objectives 

(b) process for handling risk events 
(c) team activities 

(d) team outputs. 


3. The Ashes Cricket Test is occurring in Australia and the project team responsible for planning and hosting the event has 
identified the following potential risks to their project: 


(a) umpires failing to show up at designated games 
(b) fighting between teams 
(c) pivotal error committed by an umpire that determines the outcome of a game 
(d) abusive behaviour along the sidelines by supporters 
(e) inadequate parking 
(f) not enough spectators 
(g) serious injury of a supporter. 
How would you recommend the team responds to these risks (e.g. avoid, accept) and why? 


Case | 


Alaska fly-fishing expedition 


You are sitting around the fire at a lodge in Dillingham, Alaska, discussing a fishing expedition you are planning with 
your colleagues at Great Alaska Adventures (GAA). Earlier in the day you received a fax from the General Manager 
of BlueSteel Pty Ltd. The General Manager wants to reward her top project managers by taking them on an all- 
expenses-paid fly-fishing adventure in Alaska. She would like GAA to organise and lead the expedition. 

You have just finished a preliminary scope statement for the project (see below). You are now brainstorming potential 
risks associated with the project. 


41. Brainstorm potential risks associated with this project. Try to come up with at /east five different risks. 
2. Use a risk assessment form similar to Table 17.4 to analyse identified risks. 


3. Upon identifying a number of opportunity risks, use Table 17.12 to analyse and capture details of how you would 
realise these opportunity risks. 

Project scope statement 

Project objective 


To organise and lead a five-day fly-fishing expedition down the Tikchik River system in Alaska from 21 to 25 June, at 
a cost not to exceed $27 000. 


Deliverables 


m Provide air transportation from Dillingham, Alaska, to Camp | and from Camp II back to Dillingham. 


m Provide river transportation consisting of two eight-person drift boats with outboard motors. 

m Provide three meals a day for the five days spent on the river. 

m Provide four hours of fly-fishing instruction. 

m Provide overnight accommodations at the Dillingham lodge, plus three four-person tents with beds, bedding and 
lanterns. 

m Provide four experienced river guides who are also experienced in fly-fishing. 

m Provide fishing licences for all guests. 
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Milestones 


Contract signed, 22 January. 
Guests arrive in Dillingham, 20 June 
Depart by plane to Base Camp |, 21 June. 


PWN e 


Depart by plane from Base Camp Il to Dillingham, 25 June. 


Technical requirements 


Fly in air transportation to and from base camps. 
Boat transportation within the Tikchik River system. 
Digital cellular communication devices 


pwns 


Camps and fishing conform to state of Alaska requirements. 


Limits and exclusions 


ay 


Guests are responsible for travel arrangements to and from Dillingham, Alaska. 
2. Guests are responsible for their own fly-fishing equipment and clothing. 

3. Local air transportation to and from base camps will be outsourced. 

4. Tour guides are not responsible for the number of King Salmon caught by guests. 


Customer review 
The General Manager of BlueSteel Pty Ltd. 


Source: This case was prepared with the assistance of Stuart Morigeau 
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ISO 31000:2018 Risk Management-—Guidelines, International Organization for Standardization. 
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Learning elements 


Understand the role of procurement within a project environment. 


Understand the procurement decisions/options available to a project manager. 


Be aware of the steps involved in tendering and the common tender types. 


Be aware of the steps involved in contracting and the common contract types that 


can be entered into. 


Apply the four essential elements of contract negotiation to ensure contracts are 


based on solid foundations. 


Negotiate successfully and deal with difficult situations. 


Understand the activities at contract closure, and how these may continue 


post-project in the business. 


Understand Scrum (Agile) implications in relation to contracts. 


In this chapter 


18.1 Introduction 


4 


8.2 Procurement and project 
management 


4 


8.3 Identifying procurement 
requirements 


4 


8.4 Procurement Management Plan 


4 


8.5 Purchase order decision 





4 


8.6 Tender decision: Suppliers and 
supplier selection 


18.7 Outsourcing project work 

18.8 Partnering practices 

18.9 Contract decision and contract 
types 

18.10 Procurement closure activities 
18.11 Scrum/Agile considerations 


Summary 
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18.1 INTRODUCTION 


Procurement includes the activities for planning, conducting (letting contracts) and administering 
(monitoring) procurements (e.g. contracts and/or service level agreements), and procurement 
closeout. Project procurement therefore includes ‘contracting’, but is far wider in scope interms of the 
activities that are carried out (PMI, 2017). A key factor to bear in mind during procurement activities 
is the ebligatien being made by the project manager (as a representative of the organisation) to 
enter into mutually binding (legal) agreements, where there is a monetary exchange for goods 
and services. 

Procurement requires the skills and knowledge of others beyond the immediate project team, 
such as from the procurement, contracts and legal departments of an organisation. Procurement can 
therefore be one of the more challenging areas, especially for junior and learning project managers, as 
the repercussions of making an illinformed decision can ripple beyond the project, often with serious 
litigation censeq:uences—praemenitus, praemunitus: forewarned is forearmed! 


18.2 PROCUREMENT AND PROJECT MANAGEMENT 


The procurement process can bea challenging area of project management for most project managers, 
necessitating many skills (such as communication, analysis, negotiation and business acumen) to 
be drawn upon. Although a ‘one-sizefits-all’ approach is not applicable for procurement, there are, 
nonetheless, certain key activities that are involved; these are indicated in Figure 18.1. (Note: The 
various stages and terms used in this table are covered within this chapter.) 

One of the project manager's principal activities (during the early stage of establishing the 
procurement function within the project) will be to review all of the organisation’s procurement, 
contracting and legal policies and procedures. Most project managers will therefore establish contact 
with the relevant stakeholders in each of these areas early on, in order to establish the gevernance 
between the project and the procurement department of the organisation. 

Involving the procurement department as a stakeholder on a project that. will require procurement 
support not only assists in building relationships, it also ensures the project manager is briefed 
correctly on all relevant organisational policy and procedures. The information acquired during these 
meetings should be documented within the Procurement Management Plan for later dissemination and 
communication to the project team. 

Establishing early positive interfaces (and governance) between the project and the 
organisation’s procurement. department helps to build trust and also encourages appropriate 
governance is followed in the project. On large projects, it not uncommon to have particular 
individual(s) dedicated to running the procurement and contracting function of the project 
(reporting to the project manager). This person(s) may be contracted-in for the duration of the 
project, or seconded to the project from the procurement department. The latter situation has 
the obvious benefit of bringing knowledge and experience of company procurement policy and 
procedures into the project. 

At this juncture, it may be useful to look again at. Figure 7.18: Change control Swimlane process, 
in Chapter 7, as this shows how an additional check in the project’s change request process was 
introduced to formally check for changes to conditions in contracts (and procurement considerations 
in general). 


18.3 IDENTIFYING PROCUREMENT REQUIREMENTS 


Procurement requirements should be considered early in the project life cycle and be within the 
project's scepe. In some instances, procurement activities may have even been identified within the 


CHAPTER 18 PROJECT PROCUREMENT MANAGEMENT 


Figure 148.1 Project procurement activities 
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Business Case. Although broad-brush statements might have been made about the project's approach 
to procurement, the Business Case may have specifically identified the following: 


E Long-lead time items: When a product (or service) being procured into the project has a 
long lead-time, this timeframe needs to be carefully recognised and factored in, as it will have 
the potential to delay the project's start, and/or delay the start of critical project tasks. 


E Large capital items: These items do not routinely fall into the standard project governance 
process. The tendering and contracts process can be complex and require high levels of input 
from senior stakeholders on the project. As with long lead-time items, large capital items 
should be given early and special attention in order to ensure minimal impact on schedules, 
budgets and the overall project design. 


Besides the above, the question of where procurement requirements are identified still remains. 
It may be helpful to refer back to Chapter 7 at this point as this is where a detailed discussion on the 
work breakdown structure (WBS) took place as part of the estimating process and the activities 
carried out against each work package or task. Estimates would have been identified, falling into one 
of two overarching categories: 


1. items (resources, materials or other) provided to the project from internal sources 


2. items (resources, material or other) that would have to be procured into the project. 
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The focus of this chapter is the latter. 

The project manager (supported by the project team) will need to make decisions about whether to 
make or buy during early procurement planning activities. When identifying the items to be procured, 
the project manager will be making decisions about whether the product or service is effectively being 
made within the project (as a deliverable of the project), or whether the product or service is to be 
procured into the project. Take a look at the Snapshot from Practice: Investing in investigations as an 
example of investing in the decision as to whether to make or buy. 

The range of items identified during the development of the WBS and associated project planning 
documents is often quite extensive and can include: 


E Simple precurement ef eff-the-shelf preducts: for example, a piece of equipment or a software 
package. 


E Bespeke preducts that are specially designed and manufactured fer the preject: for example, a 
steel structure building for use in regional Australia where extreme environmental factors exists. 


E Precurement ef services: for example, the provision of waste removal from a construction site. 


E The empleyment ef centracters and full-time hires te the preject: for example, the recruitment 
of a procurement manager on a fixed-term contract to the project. 


E The precurement ef a large item ef capital equipment: for example, an electrical transformer 
to supply a small township. 


These are a just few examples of the types of procurements that are typically encountered on 
projects (of all sizes and complexities). The reasons why items might be procured into a project and 
the type of procurement (contract) that. is therefore entered into, will be influenced by a large number 
of factors. For example: 


E It may be that the time constraints of the project do not allow certain items to be made within 
the project. 


E Value-formoney decisions indicate that the cost to make an item within the project is far greater 
than that of procuring the item into the project. 


@ The risk in making the item is not within the risk profile of the project and the risk cannot be 
transferred, via procurement of the item, to another party. 


E Resource availability might be a concern to the project, especially if the project manager is 
unsure of being able to obtain the required skills to ‘make’ the item within the project; the decision 
is therefore made to precure. 


@ Specialist skills/products might not be available within the organisation; therefore, the project has 
to procure these items into the project environment. 


Once identified, items to be procured are usually captured in some form of ‘bill of materials’. A 
bill of materials (BoM) is a hierarchical decomposition of all the items required by the project; 
although its origins are in manufacturing, it is equally applicable to the service industry. The BoM 
could be represented as a hierarchical structure—much like the WBS (in some projects, the WBS is 
the BoM!) or it could take the form of a spreadsheet with nested rows, indicating the breakdown 
of each component into its subsequent components. Figure 18.2A represents a visual approach, and 
Figure 18.2B a spreadsheet approach, for a fitout of a new hot-desking office. 


Figure 18.2A Visual-style of bill of materials 
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Figure 18.2B Spreadsheet-style bill of material 
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Typical information captured in a BoM includes: 


the BoM unique reference 

item name 

a description of the item 

make or buy decision 

the WBS or work package element the item is linked to 
quantity assurance criteria (e.g. standards, specifications) 
quality control activities (e.g. who, how, cost, tools) 

cost (estimate for planning) 

cost (actual, once agreed) 

estimate / quote details / links to documents 

phase, stage or date required 

procurement type (e.g. contract, tender, purchase order (PO)) 
source/supplier 

who is responsible for procuring in the project team / organisation's contracts department 
transport considerations 

storage/security considerations 

packaging/dis posal considerations 

penalties (e.g. for late delivery) 


a risk assessment of the approach taken. 


The BoM usually accompanies the projects Procurement Management. Plan, and together they 


guide the project in what to procure (the BoM) and how to procure (the Procurement Management 
Plan). Let's now review a typical Procurement Management Plan. 


18.4 PROCUREMENT MANAGEMENT PLAN 


As with the other knowledge areas, precwrement has a management plan. This could take the format. 
of a standalone document, or a section of a one-document Project Management Plan. A Procurement 


Management Plan is typically used to capture the fellowing information: 


Gevernance: This includes the relevant roles and responsibilities of those involved in 
procurementrelated activities. Using the RASCI Matrix (introduced in Chapter 14), it defines 
appropriate governance arrangements, for example, purchase order sign-off limits, tender 
reviewer arrangements, or internal project team roles and responsibilities. 


Organisatienal pelicy and precedures in relatien te precurement, centracting and legal precesses: 
On ‘procurementheavy’ contracts, it is usual working practice to have a dedicated procurement 
contact (or representative) on the project. The person who holds this role should know and be 

able to leverage a vast amount of information and knowledge about the organisation's policy and 
procedures. Capturmg this information within the Procurement Management Plan assists other 
project team members to understand the procurement process and policies of the organisation. 


Requirements ef leng lead-time items and large capital purchase items: Ensure that any items 
that fall outside the standard procurement cycles of the project are clearly highlighted. This 
would include documenting when they are needed by the project and when the latest order and 
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approval for order of these items can take place. There may be supporting tenders and sign-off 
documents if these items need to be purchased prior to a succeeding stage of the project. 


m Purchasing assumptions: Define any assumptions around the procurement of items to the 
project. For example, copper wire will fluctuate in price in line with metal market indices; 
therefore, allowances in funding these items will be made in the estimating process. 


= Market conditions: These are the background prevailing market conditions that. will influence 
decisions, such as make or buy or the purchase order / tender / contract decision. 


E Risk analysis of procurement decisions: This is usually captured within the project Risk Register 
refer to Chapter 17): for example, identifying potential risks in using a particular supplier, the 
choice of materials selected or delivery times. 


E Review of procurement lessons-learned from previous projects, and how these have been 
accommodated within the current project. 


Source: © 2018 Dr Neil Pearson 


Figure 18.3 provides an example of the type of decision-flow that may take place in practice. 
The type of procurement decides the flow through the procurement. process, that is, how the item 
is to be procured—whether by purchase order (direct to a supplier), by contract (to an already- 
established supplier) or by a full tender process. It is decisions such as this that could be captured in 
the Procurement Management Plan. 

The following sections discuss elements relevant to this process and to the decisions that have to 


be made. 


Figure 18.3 The pr 
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Can we go straight to a purchase order? 


Do we have to tender? 


N> Can we issue a contract without having to tender? 
Source: © 2018 Dr Neil Pearson 


18.5 PURCHASE ORDER DECISION 


A purchase order is the simplest route for obtaining a product and/or service into the project. An 
organisation will typically already have established who its preferred suppliers are, so there will be 
no need for the project manager to perform this arduous task. Once the BoM has been developed (see 
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Figure 18.2), the project manager/project team will (for purchase order route items) agree which of 
the company’s preferred suppliers is to be used and then start to issue purchase orders at the required 
time(s). As part of this approach, it is essential that the WBS is consulted, to ensure the selected supplier's 
lead-times allow delivery within sufficient time for the WBS work package to start on time. 

If large numbers of POs will be issued by the project, arrangements should be made with the 
finance department to ensure these will be turned around and processed in a timely manner. This is 
important to try to mitigate risk around delays to the WBS work packages. Alternatively, it might. be 
prudent to consider whether a finance department employee could be seconded into the project to 
carry out all PO activity for the project. 


18.6 TENDER DECISION: SUPPLIERS AND SUPPLIER 
SELECTION 


Most organisations have a centralised procurement and purchasing section with an established 
preferred supplier list and/or preferred panels. The project manager therefore may have to adopt 
and use these preferred supplier agreements when sourcing required products and/or services, in 
accordance with the organisation's procurement policies and procedures. Note: Preferred supplier 
agreements are usually reviewed periodically and suppliers will be advertised for, interviewed and 
selected according to predetermined criteria. 

Standing offer arrangements (SOAs) form another type of agreement for preferred suppliers. 
This involves establishing an arrangement to obtain frequently used products and/or services over a 
set period of time—meaning the project does not need to undertake formal procurement processes in 
this regard. As with preferred supplier agreements, these can save the project manager both time and 
energy. Both arrangements have obvious benefits for the organisation as a whole, including: 


contract terms and conditions have already been established 
prices have already been agreed 
delivery schedules have already been negotiated 


insurance has been arranged 


company background checks have been satisfied (Note: Dun & Bradstreet (global marketplace) 
and Company360™ (Australian marketplace) are popular sites for researching company 
backgrounds and financial information) 


E trusted business relationships enable value-adding between supplier and buyer. 


Issues can arise for a project when products and/or services fall outside of preferred supplier 
agreements or SOAs. In this situation, the project manager might consider one of two commonly used 
practices: 


1. Ad kec purchasing: This is usually associated with low-value, lowrisk and small-volume 
purchases. Three quotations are obtained and the supplier representing the best value is selected. 

2. Direct seurcing: This is usually used where specialist products and/or services are required, but 
only a limited number of suppliers (or even sole supplier) are available in the marketplace. Direct 
sourcing usually occurs with assistance from the organisation's procurement department to set 
up the required arrangements. 


18.6.1 Tenders and the tender process 


Before contract negotiations are entered into, the project manager (supported by the project team) 
may first have to undertake a formal tender process. If so, one of the first decisions to make is to 
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decide whether the tender should take the format of an open tender (where the tender is open to 
any tenderer to tender to supply the required goods and/or services) or a closed tender (where only 
selected tenderers are invited to respond to the tender process). 

Whether an open or closed tender process is used, the process usually proceeds through a number 
of steps, typically including: 


Step 1: The tender process is planned and decisions are made regarding who should participate 
inthe process, from both within the project team and the wider organisation. 


Step 2: The tender documents are prepared (see Table 18.1 for tender types). This requires 
the involvement of legal, procurement and contracts personnel from a duediligence 
perspective. In preparing the tender documents for release to the marketplace, the 
organisation needs to prepare the evaluation criteria. Some government polices 
mandate that the evaluation criteria, weighting and analysis methodologies are 
prepared prior to opening a tender for responses (see Step 3). And, further to this, that 
the criteria are published with the tender document, in an open and transparent manner. 


Step 3: The tender is opened for responses (if an epen tender) or suppliers are invited to tender 
(if a clesed tender). From a projectscheduling perspective, it must be borne in mind 
that since open tenders are typically left in the marketplace for around four to eight 
weeks, there is potential for some subsequent project tasks to be delayed, and this must 
therefore be factored in to the tasks on the final project WBS and schedule. Also, it is 
during this stage of the tender process that decisions will need to be made regarding 
how tender questions and responses are to be handled to ensure minimal delays. 


Step 4: The tender is closed. Responses are collated and distributed to the relevant parties for 
analysis. 


Step 5: The tenders are analysed by applying the evaluation criteria and weighting (defined 
in Step 2). 

Step 6: The successful supplier is notified. 

Step 7: The contract is established. 


Step 8: Once the successful supplier is contractually bound, the unsuccessful tenderers are 
duly notified. 


The timing of Steps 6, 7 and 8 is critical; it is net wise to notify the successful and unsuccessful 
tenderers of the outcome of the tender process at the same time, in case the successful tenderer 
subsequently withdraws its interest and no longer wishes to be considered. This would place the 
project in a weaker position by having to return to a (already-notified, but initially unsuccessful) 
second-choice tenderer. 


Table 18.1 Types of tender 


Request for information A request for information (RFI) is used to gather information to assist in the decision- 
making process, before any formal commitments are made. RFls can be used to obtain 
estimates during any stage of the project management life cycle, but are particularly 
useful during the scoping stage as they can obtain information which may assist the 
project in its early design. 


Request for quotation A request for quotation (RFQ) provides a detailed specification of the product and/or 
services being sought to be procured. RFQs are written in a formal, structured manner, 
with a high degree of specificity. This ensures a consistent approach can be taken in the 
analysis of the tenders. 

Contents of an RFQ could include: 


™@ purpose and background 
™@ process for questions and clarifications 
Æ technical specifications 


(Continued) 
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Table 181 Centinued 


tolerances and quality specifications 
drawings and blueprints 

terms and conditions 

a draft contract. 


An RFQ is synonymous with an invitation to bid (ITB) and an expression of interest (EOI) 
as they all (in essence) fulfil the same purpose. 


Request for proposal Request for proposals (RFPs) are, in essence, the reverse of an RFI/RFQ. Rather than 
Particular specifications being defined within the tender and the supplier responding to 
these specifics, an RFP requires the supplier to set out a design and specifications to 
solve the problem posed in the tender. 


Request for tender A request for tender (RFT) is a more formal (and official) expression of the intent to 
secure a supplier for a product and/or service. In addition to the information sought in 
an RFQ, an RFT will ask for information about the company’s financial stability, insurance 
cover and reputation (references should be sought). 


In some circumstances (e.g. government tenders) it will be indicated how the RFTs will 
be evaluated (the criteria of evaluation). The weighting of each of the criteria to be 
evaluated is typically kept confidential. 


The RFT might also be presented as an invitation to tender (ITT). 


When selecting a supplier (see Step 5) a simple spreadsheet can be used as a tool for setting out 
scores allocated to each criterion (e.g. see Table 18.2). Note that the actual number of criteria could 
be quite extensive—covering the criterion contained within the tender document, plus any further 
criteria required from a due-diligence perspective (such as financial performance of the tenderer). 

There are different ways to approach the scoring of each criterion. It is not uncommon for all 
financial and contractual aspects to be assessed by the procurements and contracts department while 
the project manager focuses on the projectspecific requirements. Another method that. may be used 
includes taking a workshop approach towards scoring each criterion. This involves key stakeholders 
within the organisation discussing and scoring the suppliers’ responses (tender responses) as a group, 
and arriving at a transparent group agreement on the final selection of the supplier. 


Table 18.2 Tenderer Selection Matrix 





Tenderer #1 Tenderer #2 
Overall score = 0.00 | Overall score = 0.00 
Score Weighted | Score Weighted 
Criteria Weight % (out of 100) score (out of 100) score 

Coverage of requirements 25 

Financial performance 10.0 

Company reputation 5.0 

Past experience in this area 5.0 

Safety record in executing 5.0 

Risks management of contract 10.0 

Performance reporting of contract 7.0 

Meets technical design requirements 40 

Favourable payment terms 7.0 

Ability to deliver on results 8.0 

After-delivery service 39 

Supplier history 12.0 

Dun & Bradstreet rating 11.0 


Demonstrates value for money 10.0 
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A more radical (but seldo mused) method involves sending out copies of the submitted tenders 
to key internal stakeholders, requesting that they individually place a score against each particular 
criterion. The resultant scores are subsequently brought together in the form of a master spreadsheet 
and the overall averages are calculated. If there is a consensus in overall opinion, that particular 
supplier will be selected. However, if there is a large variation in opinion, a workshop would need to 
be organised to facilitate a resolution of the decision. It is critical that the project manager selects 
the correct type of tender to use at each stage of the project life cycle and therefore they should 
appropriately seek input from the contracts and procurement department(s). 

New trend: Once the successful tenderer has been chosen and notified, and prior to the main 
contract coming into force, the project may wish to enter into a trial engagement to assess the 
practicalities of the contract from both sides. 


18.7 OUTSOURCING PROJECT WORK 


If the decision is made to buy into the project, then the process of outsourcing will come into play. 
The term outsourcing has traditionally been applied to transferring business functions or processes 
(e.g. customer support, IT, accounting) to other (often offshore) companies. For example, when you 
call your internet provider to solve a technical problem, you may actually end up speaking with a 
technician who is located in Bangalore, India, Bucharest or Romania. Outsourcing now means that 
significant chunks of project work are contracted out. For example, HP and Dell work closely with 
other hard drive manufacturers to develop next-generation laptops. Toyota and Daimler AG collaborate 
with suppliers to develop new car platforms. 

The shift towards outsourcing is readily apparent in the film industry. During the golden era of 
Hollywood, huge, vertically integrated corporations made movies. Studios such as MGM, Warner 
Brothers and 20th Century Fox owned large movie lots and employed thousands of full-time 
specialists—including set designers, camera operators, film editors and directors. Star actors like 
Humphrey Bogart and Marilyn Monroe were 
signed to exclusive studio contracts for a set 
number of films (e.g. six films over three years). Figure 18.4 R 





Today, most movies are made by a collection 
of individuals and small companies who come 
together to make films project by project. This 











Tool and die 
firms 


Marketing 
firm 





structure allows each project to be staffed with 
the talent most suited to its demands, rather 
than choosing from only those people the studio 
employs. This approach is also being applied 
to the creation of new products and services in 
contemporary marketplaces. 

Figure 184 depicts a situation in which 
a  ‘zero-gravity’ reclining chair is being 
developed. The genesis for the chair comes 
from a mechanical engineer who developed the 
idea in their garage. The inventor negotiates a 
contract with a catalogue firm to develop and 
manufacture the chair. The catalogue company 
in turn creates a project team of manufacturers, 
suppliers and marketing firms to create the new 
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the project. The catalogue firm brings its brand 
name and distribution channels to the project. 
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Marketing firms refine the design, develop packaging and test potential market names. Engineering 
firms provide customised parts, which are delivered to a manufacturing firm that will produce the 
chair. A project manager is assigned by the catalogue firm to work with the inventor and the other 
parties to complete the project. 

Many outsourced projects operate in a virtual environment in which people are linked by internet- 
enabled communications. They may rarely, if ever, see one another face to face. On other projects 
however, participants from different organisations may work next to each other, for example, on a 
construction site or in shared office space. In either case, people come and go as services are needed, 
much as ina matrix structure, but they are not formal members of one organisation, they are technical 
experts who form a temporary alliance with an organisation, fulfil their contractual obligations, and 
then move on to the next project. 

The advantages of outsourcing project work are many: 


1. Cost reduction: Companies can secure competitive prices for contracted-out services, especially 
if the work can be outsourced offshore. Furthermore, overhead costs are dramatically cut, since 
the company no longer has to internally maintain the contracted services. 

2. Faster project completion: Not only can work be done more cheaply, but it. might also be done 
faster. Competitive pricing means that more resources will potentially be available for the 
same dollar-cost. Furthermore, outsourcing can provide access to equipment and tools that can 
accelerate the completion of project tasks. For example, by contracting a backhoe operator 
you are able to accomplish in four hours what it might take a landscaping crew four days to 
complete. 


3. High level of expertise: A high level of expertise and technology canbe brought to bear on the 
project. The company no longer has to keep up with technological advances as this is ‘taken care 
of’. Instead, it can focus on developing its core competencies and hire firms with the know-how to 
work on relevant segments of the project. 


4. Flexibility. Organisations are no longer constrained by their own resources and can pursue 
a wide range of projects by combining their resources with talents of other companies. Small 
companies caninstantly go global by working with offshore partners. 


The disadvantages of outsourcing project work are less well documented, but here are a few: 


1. Coordination breakdowns: Coordination of professionals from different organisations can be 
challenging, especially if the project work requires close collaboration and mutual adjustment. 
Breakdowns are exacerbated by physical separation, with people working in different buildings 
and different cities, or even different countries. 


2. Loss of control: There is potential loss of control over the project. The core team depends 
on other organisations they have no direct authority over. While long-term survival of 
participating organisations depends on performance, a project may falter when one partner 
fails to deliver. 


3. Conflict: Projects are more prone to interpersonal conflict since the different participants do not 
share the same values and priorities, and potentially, culture. Trust, which is essential to project 
success, can be difficult to forge when interactions are limited and people come from different 
organisations. 

4. Security issues: Depending on the nature of the project, trade and business secrets may 
be revealed. This can be problematic if the contractor also works for your competitor. 
Confidentiality is another concern and companies have to be very careful when outsourcing 
processes like payroll and insurance information. 

Few people disagree that ‘reducing costs’ is the primary motive behind outsourcing project work. 

However, recent industry polls indicate a shift away from simply nailing the best low-cost deal and a 

shift towards securing services from companies that provide the best value in terms of both cost and 
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SNAPSHOT FROM PRACTICE Investing in investigations 





A university clearing-house whose primary value-adding = Option A would have resulted in many short-term 


unction was to match students to university courses contracts for the recruitment of external contract 
while carrying out numerous backoffice checks) was developers. 
involved in an ongoing program to replace its legacy IT Æ Option B would have been a phase@l contract, where 
systems. Due to the size and complexity of the systems, being able to proceed onto the next phase would 
he CEO committed to ‘investing in investigating’ the be determined by whether delivery of the preceding 
best option for the future development of the systems, module hae been successful. 
hie oe baen E “AEE! men HREM SIE NE m Option C would have required a much longer 

, À : contractual engagement to be entered into, most 

The project gained commitment and funds to employ $ y i 

he services of a highly regarded software development prele van a leng RSH Teg) pesia Sle s 





company, which had a sound local reputation for UCU a aleMen Sole Ze. 


investigating various options for the redevelopment of ‘Investing in investigations’ to help @etermine and 
such critical ‘core value-adding’ systems of organisations. selectthe best deployment method enabled the business 

The options the company considered for the to more comprehensively consider the long-haul costs of 
replacement of systems included: each option. Other considerations included the fit with the 
revenue stream of the organisation. Synergies with the 
business must never be ignored as contracts are generally 
legally binding once formally entered into andi if they need 
to be broken (exited) quickly because the funding model 


changes, this could potentially break a company in high 
m Option B: An external modular/phased redevelopment exit-fees and legal costs. 





m Option A: The internal redevelopment of systems— 
employing internal Agile teams to carry out requisite 
redevelopment activities over an extended 
timeframe. 


of components on a cleverly sequenced timeline of The organisation made a wise choice after reviewing 
modules. the consultant's report findings about each of the potential 
m Option C: An external 'big-bang’ development options: Option A was selected above any of the other 
approach to core modules—replacing large tracts of approaches, as the funding ane control factors, combined 
functionality in one go. with a modular approach (which enabled better quality 


access to internal stakeholders), were seen as critical to 
From a procurement perspective, each option would the project's long-term success. 
have resulted in different approaches to the procurement 
of resources to the project: Source: Pearson N 2014, ‘A university clearing house’. 


performance. ‘Performance’ is not simply limited to the quality of specific work, but also an ability to 
collaborate and work together. Companies are doing their homework to determine ‘Can we work with 
these people?’ 


18.7.1 Best practices in outsourcing project work 


This section describes some of the best practices we have observed being used by firms that. excel 
in project management (see Table 18.3). Although the list is by no means comprehensive, it reflects 
strategies used by organisations with extensive outsourcing 


5 : i . Table 18.3 Best practices in outsourcing project 
experience. These practices reveal an underlying theme in 


work 
how firms approach contracted work on projects. Instead of 
ate fa $ j a ié 1. Well-defined requirements and procedures 

the traditional ‘master-slave’ relationship between ‘owner and — 2 Extensive traininglamd team-building actviies 
provider’ or ‘buyer and seller’, all parties work together as 3. Well-established conflict management processes in place 

7 i 4. Frequent review and status updates 
par tmers; sharing the ultimate goal ofa successful project. E N A 

Differences between the traditienal approach and the 6. Fair and incentive-laden contracts 
partnering approach towards managing contracted relationships 7- Long-term outsourcing relationships 
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Table 18.4 Key differences between partnering and traditional approaches towards 


managing contracted relationships 


Partnering approach Traditional approach 


Mutual trust forms the basis for strong working 
relationships. 


Shared goals and objectives ensure common direction. 
Joint project team exists with high level of interaction. 


Open communications avoid misdirection and bolster 
effective working relationships. 


Long-term commitment provides the opportunity to 
attain continuous improvement. 


Objective critique is geared towards candid assessment 
of performance. 


Access to each other’s organisational resources is 
available. 


Total company involvement requires commitment 
from CEO to team members. 


Integration of administrative systems equipment takes 
place. 


Risk is shared jointly among the partners, which 


There is suspicion and distrust; each party is wary of 
the motives for actions by the other. 


Each party’s goals and objectives, while similar, are 
geared to what is best for them. 


There are independent project teams; teams are spatially 
separated with managed interactions. 


Communications are structured and guarded. 
Single project contracting is normal. 


Objectivity is limited, due to fear of reprisal and lack 
of continuous improvement opportunities. 


Access is limited, with structured procedures and 
self-preservation taking priority over total optimisation. 


Involvement is normally limited to project-level personnel. 


Duplication and/or translation takes place with attendant 
costs and delays. 


Risk is transferred to the other party. 


encourages innovation and continuous improvement. 


are summarised in Table 18.4. ‘Partnering’ requires more than a simple handshake! It typically entails a 
significant commitment of time and energy to forge and sustain collaborative relations among all parties. 
This commitment is reflected in the seven best practices outlined in Table 18.3. 


18.8 PARTNERING PRACTICES 


18.8.1 Well-defined requirements and procedures 


Convincing people from different professions, organisations and cultures to work together is difficult. 
If expectations and requirements are ‘fuzzy’ or open to debate, this is even harder. Successful firms 
are very careful when selecting the work to be outsourced. They often choose to contract only work 
with clearly defined deliverables and measurable outcomes. For example, contractors hire electric 
firms to install heating and airconditioning systems, electronic firms use design firms to fabricate 
enclosures for their products, and software development teams outsource the testing of versions of 
their programs. In all of these cases, the technical requirements are spelled out in detail. Even so, 
communicating requirements can be troublesome, especially with offshore providers and extra care 
has to be taken to ensure that expectations are clearly understood. 

Not only do requirements have to be spelled out, but the different firms’ project management systems 
need to be integrated. Common procedures and terminology needs to be established so different. 
parties can work together. This can be problematic when you have firms with more advanced project 
management systems working with less developed organisations. Surprisingly, this is often the case 
when US firms outsource software work to India. We have heard reports that Indian providers are often 
shocked at how unsystematic their US counterparts are in their approach to managing software projects. 

Proficient companies address this issue upfront instead of waiting for problems to emerge by 
carrying out an initial assessment of the fit. between the provider's project management methods and 
their own project management system. This fit then becomes a prime consideration when they choose 
vendors. Work requirements and deliverables are spelled out in detail in the procurement process. 
Significant time and energy is invested into establishing project communication systems to support 
effective collaboration. 
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When working with other organisations on projects, it is important to consider (and protect) your 
organisation's security (and that. of its customers). Security extends beyond competitive secrets and 
technologies to include access to information systems. Firms must establish robust safeguards to 
prevent access to sensitive information and to prevent the introduction of viruses into its systems 
from less-secure provider systems. Information technology security therefore necessitates additional 
cost and risk and this will need to be addressed upfront, before project work is outsourced. 


18.8.2 Extensive training and team-building activities 


Often, managers become so preoccupied with the plans and technical challenges involved in a project 
that they assume that pee ple issues will simply work themselves out over time. Smart firms recognise, 
however, that people issues are just as important, if not more important, than many technical issues 
and they therefore train their personnel to work effectively with people from a wide variety of other 
organisations and countries. This training is pervasive. It is not limited to management but involves 
all people, at all levels, who interact with and are dependent upon outsourcers. Trainees may attend 
a class about how to generally negotiate effectively, or may learn specific requisite skills (e.g. how 
to work effectively with Chinese programmers). Team members are provided with a theoretical 
understanding of any barriers to collaboration and are taught skills to overcome these. 

Training is augmented by inter-organisational team-building sessions, designed to forge healthy 
relationships before the project begins. Team-building workshops involve key players (engineers, 
architects, lawyers, specialists, and other staff). In many cases, firms find it useful to hire an outside 
consultant to design and facilitate the sessions. The consultant is typically well versed in inter 
organisational team building and can provide an impartial perspective to the workshop. The length 
and design of team-building sessions will depend on the experience, commitment and skill level of the 
participants. For example, in one project, where the business owner and contractors were relatively 
inexperienced in working together, a two-day workshop was convened. The first day was devoted to 
icebreaking activities and establishing the rationale behind ‘partnering’. The conceptual foundation 
was supported by exercises and minilectures on teamwork, synergy, win-win and constructive 
feedback. The second day began by examining the problems and barriers that had prevented full 
collaboration in the past. Representatives from the different organisations were each (separately) 
asked to answer the fellowing questions: 


m What actions do the other group(s) engage in that create problems for us? 
m What actions do we engage in that we think create problems for them? 


m What recommendations would we make to improve the situation? 


The groups shared their responses and asked questions to seek clarification about anything that 
was not clear to them. Agreements and disparities in the lists were noted and specific problems 
were identified. Once problem areas were noted, each group was assigned the task of identifying its 
specific interests and goals for the project. Goals were shared across groups, and special attention 
was devoted to establishing what goals they had in common. Recognition of shared geals was critical 
for transforming the different groups’ stances into a cohesive team position. Team-building sessions 
often culminate with the creation of a Partnering Charter signed by all of the participants. This 
charter states the common goals for the project, as well as the procedures that will be used to achieve 
these goals (see Figure 18.5 for an example of the first page of this charter). 


18.8.3 Well-established conflict management processes in place 


Conflict is inevitable on most projects and when disagreements are handled effectively and 
constructively, this can actually elevate performance. However, if not quickly extinguished, smoldering 
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Figure 18.5 P 









Partnering Charter 
Edwards AFB — F-22 Fighter Building 1870 a 
U.S. Air Force F-22 CTF, 411 FLTS ® Edwards AFB Civil Engineers 


Computer Science Corporation ® Lockheed Martin ® Telecom Solutions 
wr U.S. Army Corps of Engineers ® Valenzuela Engineering, Inc © VRR & Associates ig, 





We, the partners of the F-22 design and construction team, recognizing the unique nature of this project, 
commit to creating an environment of trust and communication to design and build a quality project 
which meets or exceeds the customer’s requirements. We commit to maintaining a positive and optimistic 
work environment in which all partners goals can be achieved. 


jy Oe ae Project © Safe Project 








- Meet program requirements for - Provide a safe environment. _ See 
uN F-22 Support Systems: - With no lost-time accidents. = -a 
ec let hedule and within cost 
~ eae eee w k e Maintain positive, cooperative relationships 
t 7 - Clear and open communications 
O . © Incorporate lessons learned from through appropriate channels. 


- No hidden agendas. 
- Minimum delays of paperwork. 


- Resolve problems quickly abe a Li 
he lowest level Qud Meng 


y other F-22 projects. - No surprises. 


© Create an environment for a fair and 


Vv be reasonable profit. 


. (hau tig an oe work environment. ayy ` 

Ran Qrad Qro 

ZE fe ERE ae Ge i MA 
hela gk Hack F We ge. 


‘The Partnering concept is a team relationship that pr tkete¥ the ee of mutually beneficial goals. This Partnering Charter does not create any 
legally enforceable rights or duties. Any changes to the contracts must be made by the contracting officers under the terms of the written contracts. 


dysfunctienal conflict can ignite and severely undermine project success. Outsourced activities are 
susceptible to conflicts since people are unaccustomed to working together and will have different 
values and perspectives. Smart firms invest significant time and energy upfront to establish the rules 
of engagement, so disagreements are handled constructively. 

Escalatien is the primary control mechanism for dealing with and resolving problems. The basic 
principle of escalation is that problems should be resolved at the lowest level of the management 
hierarchy, within a set time limit (e.g. within 24 hours) or they are escalated to the next tier/level 
of management. If escalation occurs, then that level/tier has the same time limit applied to resolve 
the problem er it gets passed on to the next higher level. ‘No action’ is net an option, nor can one 
participant force concessions from the other by simply delaying a decision. While there is certainly no 
shame in pushing significant problems up the hierarchy, at the same time, managers should be quick 
to point out to subordinates any problems or questions that they should have been able to resolve on 
their own without escalating the matter. 

If possible, key personnel from their respective organisations should be brought together to discuss 
any potential problems and to formulate problemsolving responses. This usually occurs as part of 
the coordinated series of team-building activities, discussed earlier. Particular attention is devoted to 
establishing the ‘change control process’ as problems often erupt around this. People who are or will 
be dependent upon each other in the project need to try to identify potential problems that may occur, 
so they can agree in advance how these should be resolved. 
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Principled negotiation emphasises collaborative problem-solving and is the norm for resolving 
problems to reach agreement in project management situations. This approach will be discussed in 
detail later in this chapter but is mentioned here to foster a linkage between conflict management and 
resolution and partnership working. 


18.8.4 Frequent review and status updates 


Project managers and other key personnel from all organisations involved will meet ona regular basis 
to review and assess project performance. Collaborating as partners is considered to be a legitimate 
project priority (which is assessed along with time, cost and performance). Teamwork, communication 
and timely problem resolution are all evaluated. This provides a platform for identifying any problems 
to do with not only the project, but also with working relationships, so these can be resolved quickly 
and appropriately. 

An increasing number of companies are using online surveys to collect data from project 
participants about the quality of working relations they experience (see Figure 18.6 for a partial 
example). With this data to-hand, one can then gauge the pulse of the project and identify any issues 
that need to be addressed. Comparing survey responses, period by period, means that areas that 
need to be improved or problems that need to be solved can be tracked over time. In some cases, 
follow-up teambuilding sessions are arranged—to focus on specific problems and to ‘recharge’ 
collaboration. 


Figure 18.6 Sample online survey 


Evaluation of partnering process: attitudes, teamwork, process. 
(Collected separately from owner and contractor participants, compared, and aggregated.) 


1. Communications between the owner/contractor personnel are 





1 2 3 4 5 
Difficult, Easy, open, 
guarded up front 


2. Top management support of partnering process is 














1 2 3 5 

Not evident or Obvious and 

inconsistent consistent 

3. Problems, issues, or concerns are 

1 2 3 5 

Ignored Attacked 
promptly 

4. Cooperation between owner and contractor personnel is 

1 2 3 5 

Cool, detached, Genuine, 

unresponsive, unreserved, 

removed complete 

5. Responses to problems, issues, or concerns frequently become 

1 2 3 Ss 

Personal issues Treated as 


project problems 
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Finally, when the time comes for celebrating a significant milestone, no matter who is responsible, 
all parties (if possible) should be invited to join in celebrating this success. This not only reinforces 
acommon purpose and project identity, but also helps to establish positive momentum for the next 
stage of the project. 


18.8.5 Co-location when needed 


@ne of the best ways to overcome interorganisational and intercultural friction is to have people 
from each organisation working side by side on the project. Smart companies rent or make available 
necessary accommodation(s) so all key project personnel can work collectively together. This allows 
a high degree of facet o-face interaction that is helpful when coordinating activities, solving difficult 
problems and forming a common bond. This is especially relevant in complex project situations 
where close collaboration from different parties is required for success. For example, the Australian 
Government. often provides common (shared) office space for key contractors responsible for 
developing disaster response plans. 

@ur experience tells us that colocation is often very important and therefore well worth the added 
expense and inconvenience (within limits, of course). When this is not practically possible, the travel 
budget for the project should contain ample funds to support timely travel to the different organisations. 

Colocation is less relevant for independent work that does not require ongoing coordination 
between professionals from different organisations. This would be the case if discrete, independent 
deliverables like beta testing or a marketing campaign are being outsourced as the normal channels of 
communication should be able to handle any coordination issues. 


18.8.6 Fair and incentive-laden contracts 


The goal when negotiating contracts is to reach a fair deal for all involved. Managers need to recognise 
that cohesion and cooperation will be undermined if one party feels they are being unfairly treated by 
others. They should also realise that negotiating the best deal in terms of price alone, could come back 
to haunt them (e.g. shoddy work, or change order gouging, where a seller sets prices at a much higher 
level than is considered fair or reasonable) 

Performanc e-based contracts, in which significant incentives are established based on the priorities 
of the project, are becoming increasingly popular. For example, if time is critical, then contractors 
accrue payoffs for beating deadlines; if sco pe is critical, bonuses are issued for exceeding performance 
expectations. At the same time, contractors will be held accountable; penalty clauses will executed if 
they (or their business, depending on their legal status or business registration type) fail to perform up 
to standard, and/or meet deadlines, and/or fail to control costs. 


18.8.7 Long-term outsourcing relationships 


Many companies recognise that major benefits can be enjoyed when outsourcing arrangements extend 
across multiple projects and are long term. For example, Corning (specialists in materials science) 
and Toyota are among the many firms that have forged a network of longterm strategic partnerships 
with their suppliers. Among the many advantages of establishing longterm partnerships are: 


E Reduced administrative costs: The costs associated with bidding and selecting a contractor are 
eliminated. Contract administration costs are reduced as partners become knowledgeable about. 
their counterpart’s legal concerns. 

m More efficient utilisation of resources: Contractors have a known forecast of work, while owners 
are able to concentrate their workforce on core businesses and avoid the demanding swings of 
project support. 

E Improved communication: As partners gain experience with each other, they develop a common 
language and perspective, which reduces misunderstanding and enhances collaboration. 
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E Impreved innevatien: The partners are able to discuss innovation and associated risks in a more 
open manner and share risks and rewards fairly. 


E Impreved perfermance: Over time, partners become more familiar with each other's standards 
and expectations and are able to apply lessons-learned from previous projects to current projects. 


Working as partners in project environments demonstrates a conscious effort on the part of 
management to form collaborative relationships with personnel from different organisations to work 
towards the successful completion of the project. For outsourcing to work, however, there needs to 
be effective negotiation to merge (while protective) interests and to discover solutions to problems in 
the project. 


18.9 CONTRACT DECISION AND CONTRACT TYPES 


Having established the requirements for procurement and undertaken necessary tendering and/or 
supplier selection activities, the next stage in project management. procurement is to consider the 
different types of contracts that may be entered into. Contracts can be highly complex and are designed 
to be legally binding. Since there can be detrimental legal and financial repercussions if a contract’s 
terms are broken, it is highly advisable for project managers to engage with their organisation’s 
procurement and contract department to determine which contract types are favoured by the 
organisation, and to canvass assistance in constructing a well-defined, legally-appropriate contract 
that protects the organisation's interests. 
Some of the contract types that may be considered for a project include: 


E build, own, operate, transfer (BOOT) 
build, own, operate (BOO) 
build, operate, transfer (BOT). 


These three types of contract contain similar elements; however, the sequence of the elements 
differentiates the type of overall contract. 


18.9.1 Build, own, operate, transfer (BOOT) 


The contract sets out that the initial asset is to be built by a specifically named contractor and 
that once the asset has been built, it is to be operated by this named contractor (or sometimes a 
new organisation, specifically set up to operate the asset, will be named). The ownership of the 
asset, at this point, stays with the contracting organisation. However, at a future time, the asset 
is handed back to the original organisation that let the contract. For example, say a government 
wishes to build a toll bridge between two major highways. The government would contract all 
elements of build, ewn and eperate to the contracting organisation. The contracting organisation, 
in this example, could be a conglomerate of large construction companies. Once the construction 
has been completed (the build would be classified as a large, complex project) the asset could be 
transferred to an organisation specifically set up to operate the asset. If operation of the asset has 
been set to 25 years, after this point, it would be returned to the government for ongoing ownership 
and operation. 


18.9.2 Build, own, operate (BOO) 


Here, the contract would be established, but there would be no intention of transferring the asset 
(e.g. the toll bridge between the two major highways) back (to the government) at a future point in 
time. The asset would remain under the ownership of the organisation that built and subsequently 
operated it (until the organisation decided to sell the asset). 
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18.9.3 Build, operate, transfer (BOT) 


The difference here is that the asset remains in the ownership of the organisation that let the contract 
originally (e.g. the government would be the owner in the above example). The building and the 
subsequent operation of the asset remain the domain of the contracted organisation. 

The reasoning behind why a particular contract type is selected over another will vary. However, 
using the example provided above: 


E The BOOT method would enable some elements of risk to be borne by the contracting 
organisation. Assuming that research has indicated the revenue from the toll bridge will exceed 
the cost of the build-and-operate activities over the life of the ownership of the asset (i.e. the 
revenue from the toll bridge over the 25 years of ownership would outweigh the cost of building 
it and its subsequent operation), this would make the contractor a profit. 


m With a BOO contract, the government would have a limited interest in any ownership of the asset 
and both the risk and the reward would be borne by the contracting organisation. 


m With a BOT contract, the asset would remain the property of the government; however, so would 
any associated responsibilities. The risk and reward of building and operating the toll bridge would 
rest with the contracting organisation. There are many complexities involved in such contracts. 


Refer to Snapshot from Practice: CLEM7 tunnel, Brisbane, Australia, for an example of a BOOT 
style arrangement. 


18.9.4 Partnerships 


A partnership is where two or more parties conduct business together, sharing the profits but also the 
risk. Partnerships are usually entered into on a 50/50 basis (this ratio can vary) and may exist under the 
guise of joint ventures, strategic alliances, consortia and teaming. Partnerships can be complex in nature 
but are often used where equal control of a project is deemed necessary. Costs fall equally between both 
parties and any profits made are distributed equally between both parties (unless specified otherwise). 


18.9.5 Fixed-price contracts 


Fixed-price contracts come in many variations: 


E Firm fixed price (FFP): FFP contracts are the most commonly occurring type of contract, where the 
price (and the sellers margin) is fixed. The price of items is fixed at the time of contract, only being 
subject to change if the scope of the work changes. The risk is borne by the seller, so if, for example, 
more effort is required to produce the goods (because the seller did not include a necessary stage of 
production), the seller still has to deliver the goods to the buyer at the agreed cost. 

E Fixed-price incentive fee (FPIF): As with a FFP contract, the price component of the contract is 
fixed; however, there is an agreement on how the margin component is constructed. For example, 
if the seller delivers ahead of time (without compromising on quality), they may be eligible for a 
performance-based incentive payment. 


E Fixed price with ecenemic price adjustment (FP-EPA): This type of contract is found less 
frequently, and is more usually applied to contracts that extend over a long period of time, or 
where items in the contract are subject to fluctuations that are not controllable by the seller. 

For example, if a seller is supplying copper cable over a long-term contract, parties to the 
contract need to recognise that there will potentially be a daily fluctuation in the price of this raw 
material on the metals exchange; therefore, there should be provisions in the contract for price 
adjustments to be made (within agreed tolerances). 


Note that while ‘incentive’ in the fixed price arrangement reduces the risk to the seller, cost 
reimbursable contracts reduce the risk to the buyer as an incentive. 
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18.9.6 Cost-reimbursable contracts 


In a cost-reimbursable contract, the legitimate costs of completed work are billed back to the 
organisation on whose behalf the work has been completed. Within this arrangement there will be a 
profit belonging to the contracting organisation, as agreed within the terms of the existing contract. 
There is a level of uncertainty with these types of contracts. 


E Cest plus fixed fee (CPFF): A fixed fee is agreed upon for an estimated amount of work 
(determined during project estimating). This fee, together with agreed allowable costs are 
subsequently billed back to the supplier. 


Æ Cest plus incentive fee (CPIF): As with CPFF, the seller is reimbursed for all allowable costs. 
The remaining fee is determined on an incentive basis. The schedule of incentive fees is agreed 
as part of the contract negotiations and is based on various performance criteria. For example, 
if laying cable underground, the seller will be paid for agreed costs and, based on the 
performance schedule, receives an incentive payment which depends on the rate of cable laid 
over a particular time period. 


E Cest plus award fee (CPAF): The buyer meets all agreed costs, but the award component is 
paid only on completion of a larger, more comprehensive overall performance goal. Taking the 
cablelaying scenario outlined in CPIF, this might mean that receipt of payment would depend 
upon the successful completion of all cable being laid into the ground and successful testing 
(as working to required specifications) of the entire cable run. 


18.9.7 Time and material contracts (T&M) 


Time and material contracts are a hybrid of both costreimbursable and fixed-price contracts. 
These are often used when a predetermined volume of work cannot be forecast, so the risk has to 
be more balanced between the buyer and the seller. Using the cable-laying scenario once more, if 
the variations in the ground to be dug up in order to lay the cable cannot be determined, the supplier 
might not be able to enter into a fixed price contract and may simply opt for a T&M contract, where 
material costs would be covered with an amount fixed perhour of labour used. 

As demonstrated, there are numerous types of contracts available. Project managers may consider 
using a particular type of contract during the Initiating and Planning stages of the project, but might 
use more of a risktransferral type of contract during project Executing stage, where the ‘unknown’ 
elements become ‘known’ elements. This is illustrated in Figure 18.7. Project managers should always 
liaise with their organisation’s legal (contracts and procurement) team before entering into any kind 
of contract; there are many potential pitfalls, therefore it is best to always seek professional, specialist 
advice. This is the case whether working with local, national or globally positioned organisations. 


18.9.8 Contracts: Four essential elements 
of a contract 
When the successful tenderer is notified, the purchasing 
organisation and supplier will enter into formal contract 
negotiations. Elements that must exist for a contract to be 
legally binding are: 


Figure 18.7 Summary of sample contract types and 


when typically used 





Seller's risk Firm fixed price (FFP) 


| Fixed price incentive fee (FPIF) 





1. offer and acceptance (agreement) gq Time and materials (T&M) 

2. the intention to be legally bound 

Be consideration a Cost plus incentive fee (CPIF) 
4. legal capacity Buyer's risk 5 Cost plus fixed fee (CPFF) 
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When entering into contract negotiations involving internal or external legal parties, the project 
manager should consider allowing additional time for these activities to take place. When dealing 
with contract law and contracts, as already pointed out, it will be necessary to consult internal 
specialist expertise but it is also prudent to obtain the professional expertise of external legal 
practitioners. 

More information may be found in Tke Law Handbeek 2018 (Fitzroy Legal Service 2018). 


18.9.9 Extended contract considerations 


The project manager should clearly specify any inclusions to be set out within the standard terms and 
conditions of the contract. For example: 


E Dispute arrangements: The procedure to be fellowed in the event of a contractual dispute 
(which cannot be resolved between the two parties) should be clearly set out and defined: 


— The conditions required for an element of the contract to be considered to be in dispute. 


— A designated independent third party should be specified and agreed upon, to host and facilitate 
dispute resolution meetings. 


— The location for any dispute resolution meetings needs to be agreed upon in advance in the 
contract. This can be particularly important if suppliers are offshore. 


— The contract needs to set out how the costs of this independent third party are to be met by the 
two main contracting parties. 


E Subcentracting: The contract should clearly indicate whether any subcontracting is to be 


allowed. Some contracts specifically state that no subcontracting is to be allowed by the 


SNAPSHOT FROM PRACTICE CLEM7 tunnel, Brisbane, Australia 





with the planned eventual transfer back to the City of 
Brisbane after a 45 year concession period. 

The CLEM7 project provides not only a good example 
of a joint venture between two major construction 
partners (Leighton Contractors an@ Baulderstone 
Bilfinger Berger), but also a good example of a BOOT 
project. The CLEM7 project also provides significant 
insight into lessons-learned@ for the way these large 
public infrastructure projects are planned: the RiverCity 
Motorway Group collapsed (in 2011) with debts of 
A$1.3 billion. The cause was stated to be largely due 
to the general public’s (wide-ranging) refusal to use the 
tunnel due to perceived exorbitant toll charges (similar 
situations to this occurred around the Lane Cove and 
Cross City tunnels in Sydney, Australia). 





Ingram Publishing/SuperStock 


RiverCity Motorway Group contracted the design and 
construction of the CLEM7 tunnel (a 6.8-km tolled 
motorway connecting five of Brisbane's major highways) 
to Leighton Contractors and Baulderstone Bilfinger Berger 


What lessons can we take away from such 
a failed project? 


as a joint venture (LBB JV). Upon successful construction 
of the CLEM/7, the operation of the tunnel and tollways 
was handed over to Queensland Tollway Company 
(RiverCity Motorway Group). RiverCity Motorway Group 
was established to build, own and operate the venture, 


Even though the build component was completed to 
schedule (actually, ahead of schedule in this case) and 
to cost, it was not apparent whether the customer (i.e. 
the very basis of the initial Business Case) had been 
considered and involved adequately enough. 
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suppliers. Buyers often do this to ensure that the quality, safety record, financial status and 
reputation of the primary contractor are not diluted by subcontracting to a third party (who 
may be unknown to the buyer). 


E Nen-disclesure agreements/cenfidentiality: Relates to how information, whether customer 
information or new product design information, is to be protected from the marketplace and from 
competitors. For example, the classification ‘commercial in confidence’ (and other classifications of 
information) may be used between the two parties. The contract should clearly define the information 
classifications to be used and set out how, and the extent to which, information needs to be protected. 


m Intellectual preperty (IP): In today's everlitigious and informationbased society, having a clear 
understanding of intellectual property (IP), copyright, patents and trademarks is critical to 
legally protecting nontangible project and organisational assets, as well as tangible products that 
are produced. 


E Perfermance and payment schedules: Clearly documented performance targets (based on 
quality criteria) need to be linked to payment schedules. Detaching the payment schedule from 
performance targets is a common error. The project has to first receive quality-based products 
and/or services (within defined tolerances), which then attract a payment. 


E Nenagreement/centract disselutien: Clauses setting out how the contract is to end should both 
parties mutually agree to dissolve the contract (and where dispute arrangements are not invoked). 


E Defects and withhelding arrangements: Contract clauses setting out the process and timeframes 
for defect correction and the amounts to be withheld/retained in the event of outstanding defects 
at project closure. 


A project manager is often faced with many potentially litigious decisions during the contract 
negotiation process. The involvement of representation from internal organisational resources (at 
minimum) is therefore critical to ensure that the contract negotiation is watertight, fair, transparent 
and will deliver what the project manager has defined. External professional legal advice should 
always be sought where there is uncertainty or where further clarity is needed. 

In Australia, there are also standards available for general conditions of contract, such as 
AS2124:1992 and AS4000:1997. Note: Both these standards are under review with a proposed AS 11000 
to supersede them in the future. 


18.9.10 The art of negotiating 


Effective negotiation is critical for successful collaboration. All it takes is one key problem to explode, to 
convert a sense of ‘we’ into an ‘us versus them’ situation. Negotiation is pervasive throughout all aspects 
of project management work. For example, project. managers must negotiate the levels of support and 
funding they will receive from top management. They must negotiate staff and technical input from 
functional managers. They must coordinate with other project managers and negotiate project. priorities 
and resource commitments. They must negotiate within their project team to determine assignments, 
deadlines, standards and priorities. Project managers must also negotiate prices and standards with 
vendors and suppliers. It is clear therefore that a project manager must have a firm understanding of how 
the negotiating process works in practice, possess requisite negotiation skills, and be able to leverage tactics 
often used during robust negotiations. When combined, these elements can help to foster project success. 

Many people approach the negotiating table as if they are in a contest. They believe that each 
negotiator is out to win as much as they can for their side. Their measure of success is how much they 
gain, compared with the other party/parties. While this approach may be applicable when negotiating the 
sale of a house, it is not true for project management: preject management is net a centest! 

The people working on the project (whether they represent different companies or differing 
departments within the same organisation) are net enemies nor competitors, but rather allies or partners. 
They have formed a temporary alliance to complete a project and for this alliance to work, a certain 
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degree of trust, cooperation and honesty is required. Although the parties within this alliance may have 
different priorities and standards, they are bound by the success of the project. If conflicts escalate to 
the point where negotiations break down and the project comes to a halt, then everyone loses. 

Unlike the bartering process with a street vendor when a person (the potential buyer) can simply 
walk away if they can’t reach agreement, the people involved on project work have to continue to 
work together. Therefore, it is fitting for them to work together to resolve disagreements in a way that. 
contributes to the long-term effectiveness of their working relationship. 

Conflict in a project can actually be good! When dealt with effectively, ‘conflict’ can lead to 
surges of innovation, better decision-making and more creative problem-solving. Project managers 
must accept this aspect of negotiation and also realise that negotiation is, essentially, a two-part 
process: where the first part of the process deals with reaching an agreement, and the second, the 
implementatien of that agreement. It is the implementing stage, not the agreement itself per se, that 
determines the success of negotiations. All too often, managers reach an agreement with someone 
only to find out later that they failed to do what they agreed to do, or that their actual response 
fell far short of expectations. Experienced project managers recognise that implementation is based 
on satisfaction—not only with the outcome, but also with the precess by which the agreement was 
reached. If someone feels bullied or tricked into doing something, this will invariably be reflected by 
a half-hearted performance. 

Experienced project managers do the best they can to merge individual interests with what is 
best for the project, to come up with effective solutions to problems. Fisher & Ury (1991) champion 
an approach to negotiating that embodies these goals. It emphasises developing ‘win-win’ solutions, 
while protecting yourself against those who would take advantage of your forthrightness. Their 
approach is called principled negotiation and is based on the four key points listed in Table 18.5 
(and discussed in the following sections). 


1. SEPARATE THE PEOPLE FROM THE PROBLEM 


Strong ‘adversarial-type’ personalities can sometimes derail substantive issues that are under 
consideration. Instead of ‘attacking’ the problem(s), people begin to ‘attack’ each other. @nce people 
feel attacked or threatened, their energy naturally goes into defending themselves, and not into solving 
the problem at hand. What needs to happen, therefore, is for them to focus on the problem—not on 
the other person—during the negotiation. This means avoiding ‘personalising’ the negotiation and not 
framing the negotiation as a ‘contest’. Instead, focus needs to be kept on the problem to be resolved. In 
Fisher and Ury's (1991) words: ‘Be hard en the preblem, seft en the peeple’. 

By keeping their focus on the issues and not on personalities, negotiators are better able to let 
the other person ‘blow off steam’ without getting emotionally involved. When dealing with important. 
problems, it is not uncommon for people to become upset, frustrated and angry. However, an angry 
attack is highly likely to produce an angry counterattack, and the ‘discussion’ quickly escalates into a 
heated argument: an emotional ‘chain reaction’. 

In some cases, people use anger as a means of intimidating and forcing concessions because the other 
person wishes to preserve the relationship. When people become emotional, negotiators should keep a 
cool head and remember the old German proverb, ‘Let anger fly eut the windew’. In other words, in the 
face of an emotional outburst, imagine opening a window and letting the heat of the anger fly out of 
the window. Avoid taking things personally, and redirect personal attacks back to the question at hand. 
Don't react. to the emotional outburst, but try to find the issues that triggered it. Skilled negotiators keep 
their cool under stress and, at the same time, build a bond with others by empathising and acknowledging 

common sources of frustration and anger. 


Table 18.5 Principled negotiation While it is important to separate the people from the problem 
1. Separate the ‘people’ from the ‘problem’ during actual negotiations, it is beneficial to have a friendly rapport 
2. Focus on interests, not positions with the other person prior to beginning negotiations. Friendly rapport 
3. Invent options for mutual gain (the win-win position) is consistent with the social network tenet of building a relationship 
4. When possible, use objective criteria 


before you need it. Reduce the likelihood of misunderstandings and 
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getting off on the wrong foot by having a history of interacting in a friendly, responsive manner with 
the other person. If, in the past, the relationship has been marked by healthy give-and-+take, in which 
both parties have demonstrated a willingness to accommodate the interests of the other, then neither 
individual is likely to adopt an immediate win-lose perspective. Furthermore, a positive relationship 
adds a common interest beyond the specific points of contention. Not only do both parties want to 
reach an agreement that suits their individual interests, but they also want to do so in a manner that. 
preserves their relationship. Each is therefore more likely to seek solutions that are mutually beneficial. 


2. FOCUS ON INTERESTS, NOT POSITIONS 


Negotiations often stall when people focus on positions: 


m Tm willing to pay $10 000. ‘No, it will cost $15 000.’ 


m ‘need it done by Monday. ‘Thats impossible, we can't have it ready until Wednesday,’ 


While such interchanges are common during preliminary discussions, managers must prevent 
this initial posturing from becoming polarised. When such positions are stated, attacked and then 
defended, each party figuratively begins to draw a line they will not cross. This line creates a win-lose 
scenario in which someone has to lose by crossing the line in order to reach an agreement. As such, 
the negotiations can become a war of wills, with concessions being seen as a loss of face. 

The key is to focus on the interests behind your positions (what you are trying to achieve) and 
separate these goals from your ego as best you can. Not only should you be driven by your interests, 
but you should try to identify the interests of the other party. Ask why it will cost so much or why it 
can’t be done by Monday. At the same time, make your own interests come alive. Don’t just say that it 
is critical that it be done by Monday; explain what will happen if it isn’t done by Monday. 

Sometimes, when the true interests of both parties are revealed, there is no basis for conflict. Take, for 
example, the Monday versus Wednesday argument. This argument could apply to a scenario involving 
a project manager and the production manager of a small, local firm that is contracted to produce 
prototypes of a new generation of computer mouse. The project manager needs the prototypes on Monday 
to demonstrate to a users’ focus group. The production manager says this is impossible. The project 
manager says this would be embarrassing because marketing has spent a lot of time and effort setting up 
this demonstration. The production manager again denies the request and adds that he has already had to 
schedule overtime to meet the Wednesday delivery date. However, when the project manager reveals that 
the purpose of the focus group is to gauge consumers’ reactions to the colour and shape of the new devices, 
not the finished product, the conflict disappears. The production manager tells the project manager that 
she can pick up the samples today if she wants because production has an excess supply of shells. 

When focusing on interests, it is important to practice the communication habit: ‘Seek first to 
understand, then to be understood’. This involves what Stephen Covey (1990) calls empathetic 
listening: allowing a person to fully understand another person’s frame of reference—revealing not 
only what that. person is saying but also how they feel. Covey (1990) asserts that people have an 
inherent need to be understood. He goes on to observe that satisfied needs do not motivate human 
behaviour, only unsatisfied needs do— People try to go to sleep when they are tired, not when they 
are rested’ (Covey 1990). The key point is that until people believe they are being understood, they 
will repeat their points and reformulate their arguments. If, on the other hand, you satisfy this need by 
seeking first to understand, then the other party is free to understand your interests and focus directly 
on the issues at. hand. ‘Seeking to understand’, however, requires discipline and compassion. Instead of 
responding to the other person by asserting your agenda, respond by summarising both the facts and 
feelings behind what the other person has said to check the accuracy of comprehension. 


3. INVENT OPTIONS FOR MUTUAL GAIN (THE WIN-WIN POSITION) 


@nce the individuals involved have identified their interests, they can explore options for mutual 
gain. This is not easy. Stressful negotiations inhibit creativity and free exchange. What is required 
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is collaborative brainstorming in which people work together to solve the problem in a way that will 
lead to a win-win scenario. The key to brainstorming is separating the ‘inventing’ from the ‘deciding’. 
Begin by taking 15 minutes to generate as many options as possible. No matter how outlandish any 
option is, it should not be subjected to criticism or immediate rejection. People should feed off the 
ideas of others to generate new ideas. When all possible options have been exhausted, sort through 
the ideas that have been generated and focus on those that. have the greatest possibilities. 

Clarifying interests and exploring mutual options creates the opportunity to dovetail interests. 
Dovetailing means one person identifies options that are of low cost to them but of high interest to 
the other party. This is only possible if each party knows what the other’s needs are. For example, 
in negotiating a price with a parts supplier, a project manager learned from their discussion that. 
the supplier was in a cash flow squeeze after purchasing a very expensive fabrication machine. 
Needed cash was the primary reason the supplier had taken such a rigid position on price. During the 
brainstorming session, one of the options presented was to prepay for the order, instead of following 
the usual ‘payment on delivery’ arrangement. Both parties seized on this option and reached an 
amicable agreement in which the project manager would pay the supplier for the entire job in advance, 
in exchange for a faster turnaround time and a significant price reduction. Such opportunities for win— 
win agreements are often overlooked because the negotiators become fixated on solving their own 
problems and fail to look for opportunities to solve the other person's problems. 


4. WHEN POSSIBLE, USE OBJECTIVE CRITERIA 


Most established industries and professions have developed standards and rules to help deal with 
common areas of dispute. For example, both buyers and sellers rely on ‘the blue book’ to establish 
price parameters for a used car. The construction industry has building codes and fair practice 
policies to resolve proof of quality and safe work procedures. The legal profession uses precedents to 
adjudicate claims of wrongdoing. 

Whenever possible, you should insist on using external, objective criteria to settle disagreements. 
For example, a disagreement arose between a regional airlines firm and the independent accounting 
team entrusted with preparing the annual financial statement. The airline firm had made a significant. 
investment by leasing several used airplanes from a larger airline. The dispute involved whether this 
lease should be classified as an operating or capital lease. This was important to the airline because if 
the purchase was classified as an operating lease, the associated debt would not have to be recorded 
in the financial statement. However, if the purchase was classified as a capital lease, then the debt 
would be factored into the financial statement and the debt/equity ratio would be much less attractive 
to stockholders and would-be investors. The two parties resolved this dispute by deferring to formulas 
established by the Financial Accounting Standards Board. As it turns out, the accounting team was 
correct but, by deferring to objective standards, it was able to deflect the disappointment of the airline 
managers away from the accounting team and preserve a professional relationship with that firm. 


DEALING WITH UNREASONABLE PEOPLE 


Most people working on projects realise that, in the long run, it is beneficial to work towards mutually 
satisfying solutions. Still, occasionally you encounter someone who has a dominant win-lose attitude 
about life and they are difficult to deal with. Fisher & Ury (1991) recommend using negetiatien jujitsu 
when dealing with such a person. That is, when the other person begins to push, don’t push back. As in 
the martial arts, avoid pitting your strengths against another's directly; instead use your skill to step aside 
and turn that person's strength to your ends. When someone adamantly sets forth a position, neither reject 
it, nor accept it. Treat it as a possible option and then look for the interests behind it. Instead of defending 
your ideas, invite criticism and advice. Ask why it’s a bad idea and discover the others underlying interest. 

Those who use negotiation jujitsu rely on two primary weapons. They ask questions instead of 
making statements. Questions allow for interests to surface and do not provide the opponent. with 
something to attack. The second weapon is silence. If the other person makes an unreasonable 
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proposal or attacks you personally, just sit there and don’t say a word. Wait for the other party to 
break the stalemate by answering your question or coming up with a new suggestion. 

The best defence against unreasonable win-—lose negotiators is having what Fisher & Ury refer to 
as a ‘strong BATNA’ (Best Alternative To a Negotiated Agreement). They point out that people try to 
reach an agreement to produce something better than the result of not negotiating with that person. 
What results would be the true benchmark for determining whether you should accept an agreement. 
A strong BATNA gives you the power to walk away and say, ‘No deal unless we work towards a win- 
win scenario’. 

Your BATNA reflects how dependent you are on the other party. If you are negotiating price and 
delivery dates and can choose from a number of reputable suppliers, then you have a strong BATNA. 
If, on the other hand, there is only one vendor who can supply you with specific, critical material 
on time, you have a weak BATNA. Under these circumstances you may be forced to concede to the 
vendor's demands. At the same time, you should begin to explore ways of increasing your BATNA for 
future negotiations. This can be done by reducing your dependency on that supplier. Begin to find 
alternative substitutable materials or negotiate better lead times with other vendors. 

Negotiating is an art (as well as a science) and there are many intangibles involved in the process. 
In this section, we have reviewed some useful and time-tested principles (based on the celebrated 
work of Fisher & Ury 1991) that can help to foster effective negotiations. Given the significance of 
negotiation in project management, Fisher & Ury’s work is a helpful timetested resource and there 
are many other resources available that can be of use. Negotiation training workshops can provide 
opportunities to practise these skills face to face and you should also take advantage of dayto-day 
interactions to sharpen your negotiating acumen. 


18.10 PROCUREMENT CLOSURE ACTIVITIES 


Procurement closure has been considered throughout this chapter (in sections 18.6 and 18.9). 
Figure 18.8 (in three parts) illustrates some additional end-of-project procurement activities and also 
indicates how they may be taken forward by the organisation ‘postproject’. 

Further project closure procurement considerations are covered in Chapter 19 and Chapter 6. 
Note: In the PMB@K sixth edition, ‘Close procurements’ has indeed been moved into the ‘Close project 
or stage’ section. 


actual project close 
















Deliverables 
e Final deliverables signed-off 
e Quality verified 
Fix/defect arrangements established 
Warranty arrangements established 
Handover completed 
Cost closeout 
e Withholding amounts for defects 
e Additional payments for performance targets 
e Invoices reconciled and final payments made 
e Contractor/supplier performance review 
Retention arrangement established 


e Contract delivery - 
The point at which 
all the contract 
deliverables would 
have been achieved 


Source: ® 2018 Dr Neil Pearson 
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. 
Express warranty clauses enforced Warranty 


Implied warranty enforced (consumer penon mhe 
and other acts) contract is 
Withholding (bonds) amounts retained still running 
* 5% of contract value 
e Defect/fix — 
Defect/fix (snag list) list items resolved Na eee 
Proportion of withholding monies Fecified/sertonmed 


released on defect/fix list resolution 


e 2.5% of the 5% held for warranty 
cover 


Source: ® 2018 Dr Neil Pearson 


Figure 18.8C Summary of activities at formal contract discharge, after any warranty/defect 


arrangements have expired 


Monterhg and canttaing processes 





EE 





e Contract 
discharge 





Discharge of a contract occurs when 
contract is legally completed. 

e Hopefully occurs for you when all 
involved parties complete the contract 
as agreed! 

e The alternative is accord’. 

Final supplier performance review 









Source: @ 2018 Dr Neil Pearson 


‘An agreement (accore) between two contracting parties to accept alternate performance to discharge a preexisting duty between 
them and the subsequent performance (satisfaction) of that agreement. 


18.11 SCRUM/AGILE CONSIDERATIONS 


As we know, there is a stark difference between the approach of Predictive project management (i.e. 
the Project Management Institute’s approach) and that of Scrum (iterative and incremental) project 
management. ®ne key difference that has affected the manner in which contracts are developed and 
applied is that. of the lack of upfrent requirements. When requirements are only agreed for inclusion 
in the sprint at the sprint planning meeting and, at this point, the contracting supplier is being issued 
with the work, how cana contract be formed? Even if the supplier was consulted at the outset when an 
emerging product backlog was being developed (before any epics, increments or sprints were outlined) 
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the supplier still does not know what will end up in the sprint, until the sprint planning meeting has taken 
place. This uncertainty (risk) is one of the key drivers to changing relationships that organisations have 
to accommodate when moving to a Scrum (Agile) approach. Listed below are some of the dynamics that 
need to be considered when building contracts for a Scrum (Agile) approach towards outsourcing the 
sprint development activities. 


=m Involve the supplier early on as this helps to foster trust. Although there can be no guarantee 
about the total amount of work that will be contracted out, the supplier can be engaged on the 
premise that whatever work is carried out, they will be the selected supplier. 


@ Sprint goals are useful for driving performance: consider how measures of success can inform 
reward (pay) (e.g. the number of stories completed to quality acceptance criteria). 


@ Risk/reward is shared between the organisation and the supplier in equal proportions. Rewards 
(savings) are shared back with the project, and risks realised are appropriately shared between 
the project and supplier according to predetermined criteria. 


@ Access by the supplier to various stakeholders in the business can be a sticking point. As this situation 
can quickly cause delays within a sprint, the conditions of access need to be defined very carefully. 


@ Scrum projects are liable to fail faster—feedback to the business is immediate at the sprint review 
and the next sprint may not go ahead based on the changing business environment. If there is the 
possibility that a supplier will be providing services for only a short period of time, the standard 
clauses of contract termination may now need adjusting. 


@ Consider evolving new contract types, such as: 


— Capped time and materials: This is a modified T&M contract, where a fixed agreed upper 
cap is placed on the contract. The supplier benefits in being able to recover upfront expense 
early on in charges, and the organisation benefits by having a cap on costs. 


— Cost targeted contracts: A realistic price for the final product is agreed upfront. Work 
is paid on the basis of this final price. These types of contracts are more often used in the 
manufacturing and construction industries, but could be adapted for use in an Agile (Scrum) 
project. 


— Modified piece work: Not the realms of turn of the century Victorian industry, but a price 
associated with story-points, or a sprint/increment (of a standard duration). 


Generally, because of the unknown duration of a Scrum (Agile) project in total, do not be surprised 
if a risk/reward arrangement cannot be entered into, and that you as an organisation, may be paying 
inflated prices to cover the risk of the potential shor t-term nature of the project from sprint to sprint. 
The outsourcing or contracting out of sprint development work is an evolving area of the Scrum 
(Agile) approach to project management;the reader is encouraged to search the internet for current 
practices in this area. 


Procurement can be quite an arduous activity from a project manager’s perspective, and the complexities of the 
Procurement function in a project environment should not be underestimated. Potential impacts on the project 
schedule and project resources must be considered in some detail to ensure adequate time and resources are made 
available, not only to prepare tenders and negotiate contracts, but also to ‘performance manage’ them throughout the 
life of the project. 


m Procurement activities often involve other parts of the organisation, such as the procurement and contracts 
department(s) or, in some situations, the legal department. 
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Engaging representative stakeholders (with their respective knowledge from areas of the business) can reap great 
dividends as the project progresses. 

Paying particular attention to the finer details of the terms and conditions of contracts is important as this can help 
to remove as much uncertainty (from both a buyer's and seller’s perspective) as possible. We have looked at the 
importance of tightly defining the requirements of items to be procured, discussing how this becomes especially 
important when the contract is executed as these criteria can provide the basis for performance management of the 
contract, and resulting payments to the supplier. 

Building positive professional relationships with suppliers is an important function within procurement. Creating 
professional two-way trust and building understanding of the project requires a project manager to invest time 
energy and robust communication skills. 

During closure of the project, the project manager has to ensure that all activities are directed towards contract 
closure and that all products and/or services have been delivered to specification and relevant payments have been 
made. Any defect lists need to be agreed and appropriate (or pre-agreed) amounts of monies held back. 

Once all warranties and outstanding defects have been handed over to the business as part of project closure, the 
project manager will be responsible for notifying the procurement and contracts department of any lessons-learned. 
This is especially important for lessons-learned regarding non-performance or sub-performance by any supplier or 
contractor. 

Finally, we addressed the implications for Scrum (Agile) projects and the evolving literature on how tenders, contracts 
and procurement in general are adapting to fit the Scrum (Agile) approach 


https://www.dnb.com 

https://company360.illion.com.au 

www.lawhandbook.org.au 

https://www.apm.org.uk/body-of-knowledge/delivery/resource-management/procurement/ 

https://www.standards.org.au/news/as- 1 1000-colon-general-conditions-of-contract 

http://www. firebrandtraining.co.uk/learn/pmp/course-material/project-procurement-management/ 
plan-procurement-management 

https://www.law.cornell.edu/wex/accord_and_satisfaction 


BATNA cost-targeted contracts principled negotiation 
bill of materials (BoM) fixed-price contract (FFP, FPIF, procurement 
build, own, operate, transfer (BOOT) FP-EPA) purchase order (PO) 

contract four essential elements of a contract request for information (RFI) 
build, own, operate (BOO) contract large capital items request for proposal (RFP) 
build, operate, transfer (BOT) contract long lead-time items request for quotation (RFQ) 
capped time and materials contract main contract request for tender (RFT) 
closed tender make or buy (decision) standing offer arrangements (SOAs) 
contract discharge modified piece work contract tender process 
contract law open tender time and material (T&M) contracts 
contract types outsourcing trial engagement 
cost-reimbursable contract (CPFF, Partnering Charter warranty period 

CPIF, CPAF) 


Review questions 


1. Define your understanding of project procurement 
2. What is the ‘make or buy’ decision? 
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What are the differences between an RFI, RFQ, RFT and RFP tender? 

What are the elements of a legally binding contract? 

When would a time and materials (T&M) contract be used? 

What is the key difference between a fixed price contract and a costreimbursable contract? 

What are the key steps involved ina tender process? 

What steps can be taken during negotiation to assist in a constructive outcome for all parties involved? 


wponan sw 


What are some benefits of outsourcing? When is outsourcing likely to be used in a project context? 
10. What considerations should be taken into account when contracting in a Scrum (Agile) project? 


1. In the case of the CLEM/ tunnel example provided (see Snapshot from Practice: CLEM7 tunnel, Brisbane, Australia), 
what do you think could have been done in the project to better assess potential customer demand for using the tunnel 
and the toll pricing to be levied? 


2. What additional organisationspecific activities would you include in the integration of procurement that may not be 
covered in Table 6.10: Project procurement integration, in Chapter 6? 


3. Reflect back ona recent project you have been involved in which necessitated contractual negotiations. How did the 
negotiations consider the four essential elements of a contract? 


Case 


The accounting software installation project 


Sitting in her office, Karin Chung is reviewing the past four months of the large corporate accounting software 
installation project she has been managing. 


Four months ago: Planning the project 


Everything seemed so well planned before the project started. Each company division had a task force that provided 
input into the proposed installation, including raising potential problems. All the different divisions had been trained 
and briefed on exactly how their division would interface and use the forthcoming accounting software. All six 
contractors, which included one of the Big Five consulting companies, assisted in developing the WBS—costs, 
specifications, time. 

Karin hired a consultant to conduct a one-day partnering workshop, which was attended by the major accounting 
heads, a member of each task force group, and key representatives from each of the contractors. During the 
workshop, several different team-building exercises were used to illustrate the importance of collaboration and 
effective communication. Everyone laughed when Karin fell into an imaginary acid pit during a human bridge-building 
exercise. The workshop ended on an upbeat note with everyone signing a Partnering Charter that expressed their 
commitment to working together as partners to complete the project. 


Two months ago 


One task force member came to Karin to complain that the contractor dealing with billing would not listen to his 
concerns about problems that could occur in the Brisbane division when billings are consolidated. The contractor 
had told him (the task force member) that he had bigger problems than consolidation of billing in the Brisbane 
division. Karin replied, ‘You can settle the problem with the contractor. Go to him and explain how serious your 
problem is and tell him that it will have to be settled before the project is completed’ 

Later in the week in the lunchroom she overheard one consulting contractor bad-mouthing the work of another— 
‘never on time, interface coding not tested’. In the hallway the same day, an accounting department supervisor told 
her that tests showed the new software would never be compatible with the Perth division’s accounting practices. 
While concerned, Karin considered these problems typical of the kind she had encountered on other smaller 
software projects. 
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Today 


The project seems to be falling apart. What happened to the positive attitude fostered at the team-building 
workshop? One contractor has written a formal letter complaining that another contractor was sitting ona coding 
decision that was delaying their work. The letter says: ‘We cannot be held responsible or liable for delays caused 
by others’. The project is already two months behind, so problems are becoming very real and serious. Karin finally 
decides to call a meeting of all parties to the project and partnering agreement 

She begins by asking for problems people are encountering while working on the project. Although participants are 
reluctant to be first for fear of being perceived as a complainer, it is not long before accusations and tempers flare 
out of control. It is always some group complaining about another group. Several participants complain that others 
are sitting on decisions that result in their work being held up. One consultant says, ‘It is impossible to tell who's in 
charge of what’. Another participant complains that although the group has met separately on small problems, it has 
never met as a total group to assess new risk situations that develop. 

Karin feels the meeting has degenerated into an unrecoverable situation. Commitment to the project and partnering 
appear to be waning. She quickly decides to stop the meeting and cool things down. She speaks to the project 
stakeholders: 

‘It is clear that we have some serious problems, and the project is in jeopardy. The project must get back on track, 
and the backbiting must stop. | want each of us to come to a meeting Friday morning with concrete suggestions for 
getting the project back on track and specific actions for how we can make it happen. We need to recognise our 
mutual interdependence and bring our relationships with each other back to a win-win environment. When we do 
get things back on track, we need to figure out how to stay on track.’ 


1. Why does this attempt at project partnering appear to be failing? 
2. If you were Karin, what would you do to get this project back on track? 
3. What action would you take to keep the project on track? 


Appendix 18.1, R equest for Tender (RFT) is available online. 
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Learning elements 


Successfully close out a project, taking into account project reporting, human 
resources, financials, procurement, contracts and other lessons-learned. 


Understand what a post-implementation review (PIR) is and why the project 
manager is a key input into this activity. 


Further understand the significance of deliverable ‘handover’ and ‘sign-off’ to the 
customer: revisiting the original scope of the project, to ensure deliverables have 
been delivered and that the project has met its critical success criteria. 


Be able to understand performance across the multiple dynamics of a project, 
including project performance, team performance, individual performance and 
contractor/supplier performance. 


Be able to describe how benefits are delivered within the project and/or handed 
over into the business for post-project delivery. 


In this chapter 


19.1 Introduction 

19.2 Types of project closure 
19.3 Closure activities 

19.4 Performance evaluation 
19.5 Lessons-learned 

19.6 Benefits realisation 
19.7 Project celebration 


Summary 
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19.1 INTRODUCTION 


Every project comes to an end eventually. But how many project participants get excited about clesing 
eut a project? The deliverables are complete. @wnership is ready to be transferred. Everyone’s focus 
is on what's next—hopefully another new, exciting project. The careful and skilful management of 
the Closing stage is just as important as the management of any other stage or activity of the project. 
@bservation tells us that organisations that manage the review and closure of projects prosper. 
@rganisations that don’t manage either of these endeavours will tend to have projects that drag on 
forever and never truly hand over to the operational business. 

Closing out a project can necessitate a seemingly daunting number of tasks. Traditionally (and for 
small projects), the project manager alone was responsible for seeing that all tasks and loose ends 
were completed and signed off. This is no longer true, as in today’s project-driven organisations, which 
often have many projects occurring simultaneously, responsibility for completing closure tasks often 
gets split. between the project manager, the project management office (PM®), the finance department, 
and procurement and contracts departments. Many tasks overlap, occur simultaneously, and require 
coordination and cooperation between stakeholders. 

There are a number of activities that need to be undertaken during the Closing stage of a project, 
including performance evaluation and the evaluation of lessons-learned (see Figure 19.1). 


1. Clesing the preject: The major project closure task is to ensure that the project is approved 
and accepted by the customer. ®ther closure activities include closing accounts, paying 
invoices, reassigning equipment, releasing and reassigning personnel, finding new opportunities 
for project staff, closing facilities and the final report. Checklists are used extensively to ensure 
tasks are not overlooked. In many organisations, the lion’s share of closure tasks are largely 
carried out by the PM®, in coordination with the project manager. The final project closure 
report is the responsibility of the project manager. However, responsibility for carrying out the 
post-implementation review (PIR) is usually assigned to a PM@ staff member, who assembles 


input from selected stakeholders—for example, the customer, the sponsor, the project manager 
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and project team members. In smaller organisations and projects, these closure activities are 
typically left to the project manager and the team. 


2. Evaluation ef perfermance and management ef the preject: The process of evaluation involves 
assessing the performance of the project team (as a group); individual team members, suppliers, 
contractors; and the project manager (both their performance and project management skills). 
Evaluating the performance of these major players can generate important insight into who 
(and who not) to employ or enter into contracts with in future projects. 


3. Lessens-learned (known as the retrespective in the Scrum approach): Lessons that have been 
learned through previous project experience(s) can be applied to inform improved performance 
in current and future projects. Today, many lessons-learned workshops are run by independent 
facilitators. Post-project reviews held with the team help to catch any remaining issues and 
also any holistic (whole-of-project) lessons that can be passed back into the greater business 
operations. PIRs should be carried out. prior to the team being disbanded and/or prior to key 
people leaving the project—timing of this activity can therefore be critical and should be built 
into the project's schedule at the Planning stage of the project. 


The results of project (or stage) closure are typically made explicit (i.e. they are documented) within 
a number of project-related documents, including: the Business Case, the Benefits Realisation 
Plan and the Lessons-Learned Register. These, together with the final project closure report and 
the PIR report, should be presented to various groups of stakeholders in the business and eventually 
archived in the project library for reference by future project managers. Table 19.1 summarises who 
the audience might be for such documents. 


Table 19.1 Key project closure documents 













Business as Future project 
usual managers 


Business Case x x 

Benefits Realisation Plan x x 
Lessons-Learned Register 

Project closure report x 


Document 


Post-implementation review (PIR) 


|< | | x 


Project library (archive) 


Source: @ 2018 Dr Neil Pearson 


This chapter begins by pointing out that projects can be closed for many reasons: not all projects 
end with a clean finish. Regardless of the conditions for ending a project, the general closure process 
will be similar, although the endings may differ significantly. Wrap-up or clesure tasks are tasks 
that represent all of the activities that must be cleaned up before the project is closed. After this 
has occurred, an evaluation of project performance takes place and lessons-learned are examined 
and recorded in detail. Actions are set to ensure these lessons are applied to the business and future 
projects. 


19.2 TYPES OF PROJECT CLOSURE 


@n some projects, the end of the project may not be as clear as hoped for. Although the scope document 
may define a clear ending for a project, its actual ending may or may not correspond. Fortunately 
though, the vast majority of projects do meet their well-defined end. The different types of closure can 
be described as normal, premature, stage, perpetual, failed project or changed priority, as outlined 
below. 


588 
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19.2.1 Normal 


The most common circumstance for project closure is simply @ cempleted preject. For many 
developmen ttype projects this will mean handing over a final design to production, and the subsequent 
creation of a new product or service line. For internal ICT projects (e.g. major system upgrades or the 
creation of a new inventory control system) the end of the project will occur when its deliverables 
are incorporated into ongoing operations. Typically, some modifications to the scope, cost and/or 
schedule will have occurred during the project’s life cycle; although these would have been approved 
and included into the scope of the project and therefore its final deliverables. 


19.2.2 Premature 


The premature ending of a project could arise from any number of reasons—for example, due to a 
change of management, a change of businesses strategy, a faltering/slowdown of the economy, the 
sponsor moving onto other priorities, or the project failing to progress through a gateway review 
because the Business Case is no longer valid. Gateway reviews are often nicknamed a ‘kill-point’ for 
that very reason. 

Completion also arrives prematurely for a few projects due to some parts of the project being 
eliminated. For example, in a new product development project, the marketing manager may insist on 
being supplied with production models before they have been tested: ‘Give the new product to me now, 
the way it is. Early entry into the market will mean big profits! I know we can sell a bazillion of these. 
If we don't do it now, the opportunity will be lost!’ 

In this scenario, the pressure will be on the project manager to finish the project and send it to 
production as quickly as possible. However, the implications and the risks associated with making the 
decision should be carefully reviewed and assessed by senior management and by all stakeholders. 
All too frequently, perceived benefits turn out to be illusory, dangerous and hugely risky. 


19.2.3 Stage 


Although this chapter discusses steps towards closing down a project atits ultimate end, it should be 
noted that most elements of project closure can also be applied at the end of each stage of the project 
life cycle, or at particular stages in the project design. To help clarify this, refer back to Chapter 2, 
Figure 2.13 (sequential-staged approach), Figure 2.14 (overlapping-staged approach) and Figure 2.15 
(iterativestaged approach) and consider where clesure activities could be applied in each of these 
approaches. 


19.2.4 Perpetual 


Some projects never seem to end! A major characteristic of this kind of project are constant add-ons, 
suggesting the presence of a poorly conceived project scope and a poorly applied project management 
approach. @rganisations should regularly review all project activity and ensure no perpetual projects 
exist, and if identified, bring them to a swift close via the formal project closure steps. 


19.2.5 Failed project 

Failed projects are usually easy to identify and are easy for a review group to close down. However, 
every effort should be made to communicate the reasons for termination of the project. In any event, 
project participants should not be left with any kind of stigma for having worked on a project that 
failed. Many projects will fail because of circumstances beyond the control of the project team. 


19.2.6 Changed priority 


@rganisations’ priorities often change and their strategies will therefore shift in direction. For example, 
during the 2008-18 global financial crisis (GFC), many organisations shifted their focus away from 
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money-making projects towards cost-saving projects. Each organisation’s oversight group will 
continually revise project selection priorities to reflect changes in organisational direction. Projects 
that are already in progress may need to be substantially altered or cancelled. Thus, a project may 
start as a high priority but see its ranking erode or crash during its project life cycle, as conditions 
change. 

When closure does occur, a number of activities must take place to ensure that maximum value, 
for future projects, is extracted from the project’s closure—refer to Figure 19.1. The next section of 
this chapter discusses some of these closure activities. 


19.3 CLOSURE ACTIVITIES 


By this stage, the major challenges for the project manager and for the team members will be over. 
However, getting the project manager and the project participants to wrap up odds and ends in order 
to fully complete a project can be difficult. It’s like asking, ‘The party is over—now who wants to help 
clean up?’ Much of this work is mundane and tedious. Motivation and staff retention can be chief 
challenges. For example, accounting for equipment and completing final reports is often perceived 
as dull administrative tasks by project professionals, who are action-oriented individuals. The project 
manager's task therefore is to keep the project team focused on the remaining project activities and 
on final delivery to the customer, until the project is complete. Communicating a Closure and Review 
Plan and schedule early-on allows the project team to: (1) psychologically accept the fact that the 
project will end and (2) prepare themselves to move on. The ideal scenario would be to have each team 
member's next assignment ready at the stage that the current project's completion is announced (note 
that such activities were discussed in Chapter 13). Project managers need to be careful to maintain 
their enthusiasm for completing the current project and must continue to hold people accountable for 
deadlines (which are prone to slip during the waning stages of the project). 

Implementing the closure process can include many activities. Some organisations develop lengthy 
lists for closing projects as they gain experience over time. These can be very helpful for ensuring that 
nothing is overlooked. Implementing closure includes the following key activities: 


1. Gaining final deliverable (outcomes and outputs) acceptance from the customer (final sign-off). 
2. Shutting down resources (releasing to new uses or disposing of). 

Releasing project team members. 

Closing accounts and seeing that all invoices are settled (refer to Chapter 1@). 


Closing down procurements and supplier contracts (refer to Chapter 18, section 18.10). 


Congratulating the project team and celebrating. 


3. 

4 

5 

6. Creating a final report and archiving the project library. 

T, 

8. Communicating outcomes and ‘thank you’ to the wider project stakeholder community. 
9 


Reviewing the Business Case, benefits, critical success factors (CSFs) and key performance 
indicators (KPIs). 


Administering the details of closing out a project can be intimidating. Some organisations have 
checklists of ever 100 closure checks and tasks! These checklists deal with closure details such as 
facilities, teams, staff, customers, vendors and the project itself. A partial example administrative 
closure checklist is shown in Table 19.2. Note that most good PM@s will have such lists available to 
the project manager. 

@btaining delivery-acceptance by the customer is a major and critical closure activity. Delivery of 
some deliverables to the customer will be straightforward. @thers will be more complex and difficult. 
Ideally, there should be no surprises. This necessitates having a well-defined scope, plus an effective 
change request system with active customer involvement (user involvement is critical to acceptance). 
Note that experienced project managers will rarely have a single signoff of the project's deliverables 
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Table 19.2 Project closure checklist 


Date checked | Actions | Owner 
Team (human resource (HR)) 


Have the team members been thanked for their individual contributions? 
Have the project successes been communicated to the various stakeholder groups? 
Have arrangements been made to release or return staff? 


Have relevant project team members been performance-appraised and (as required) have their line 
managers been briefed on their performance? 


Have contractors been released, contracts closed out, and procurement blacklists revised with the details of 
any underperforming organisations? 


Have the project successes been celebrated (project closure celebration)? 
Does the HR department need to be included in a career counselling capacity? 
Financial/procurement 





Have all outstanding invoices been recorded? 
Have all contracts been closed out? 

Have all purchase orders been closed out? 

Has access to IT and other systems been revoked? 


If the project team is disbanded before financial closure of the project takes place, has a responsible 
commercial manager (or other accountable person) been committed to close out the project’s 
final accounts? 


Have rental or leased equipment agreements been closed out, equipment returned, and deposits recouped? 
Have all warranties/guarantees been handed over to relevant persons within the organisation? 


Has a fix (defect) list been agreed with suppliers and have appropriate withholding amounts been retained 
by the business? 


Sponsor/customer and scope 


Have all project deliverables been completed and approved (accepted), considerate of approved change 
requests? 


Is all acceptancetesting complete and have any outstanding issues been resolved or placed on an agreed 
‘defect’ list? 


Have all business owners been notified, and have they agreed to the handover of the relevant deliverables? 
Have these formally been signed off? 


Have relevant benefit owners been notified, and have they accepted responsibility for tracking ongoing 
benefits once these are handed over to the business? 


Has an in-depth project review and evaluation interview been conducted with the customer? 


Have users been interviewed to assess their satisfaction with the project deliverables/with the project team/ 
with vendors/with training/with support/with maintenance etc.? 


Communications 


Has the project’s closure and success been communicated to stakeholders (internal and external) to the 
project? 


Have all formal communications related to the handover of the deliverables been completed? 
Have all final project status reports been completed and presented to the relevant bodies? 
Project administration 

Has the project library been updated (including final and accurate project financials)? 

Has a lessons-learned workshop been completed? 

Have all lessons-learned been captured, and actions allocated? 

Has the final project closure report been formally signed off and accepted by relevant bodies? 
Has the PMO been provided with all documents and project information? 

Has the PMO (or appropriate external or internal body) carried out a PIR? 


Source: © 2018 Dr Neil Pearson 


at the end of a project. This is because best practice indicates that deliverables should be planned 
into the project schedule and signe doff as they are delivered throughout the entire project life cycle. 
This process is illustrated in Figure 19.2, where a number of deliverable IDs (DID) are indicated 
along the life cycle of the project. Each deliverable would be formally signed-off using a deliverable 
acceptance form, thereby reducing the uncertainty (risk) of final acceptance at project closure. 
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Figure 19.2 Deliverable 
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The conditions for completing and transferring the project should be established before the 
project begins. A completed software program offers a good example of how specific details will 
need to be worked out in advance: for instance, if the user has problems using the software, will the 
customer withhold final payments? Who will be responsible for supporting and training the user? 
If these conditions are not clearly defined within the scope document, getting acceptance/approval 
of delivery can be troublesome. Some projects define what are called ‘critical success factors’ 
(CSFs) within the project scope document. These, along with the deliverables and objectives, are 
then used to confirm delivery and to secure final payments, and/or final sign-off of the project from 
the customer. 

A gradual release of the project team typically occurs during the Closing stage. For some team 
members, termination of the activities they have been responsible for ends before the project is 
delivered to the customer, in which case, reassignment of these participants needs to take place well 
before the final finish date. For the remaining (full-time or part-time) team members, termination 
may result in either them becoming involved in a new project, or them returning to their functional 
(substantive) role. Sometimes, team members will be assigned to operational positions and will play 
an active role in the production of the new product or service once it has been handed over to the 
business. This provides a solid base for knewledge transfer between the project, and the handover 
to the business. For contracted workers, this stage of project closure may mean the end of their 
assignment to this particular project. In some cases, there may be followup work available or user- 
support possibilities. It may be that a small number of parttime participants is recommended to the 
user organisation to train their staff or to operate the new equipment or systems delivered. 

Since many work invoices will not be submitted until after the project is officially over, closing 
out contracts can be messy and fiddly as there may be multiple loose ends that need to be tied up: it 
is realistically improbable that all submitted invoices will have been finalised, billed and then paid 
(settled). Also, when contractors are used there is a need to verify that all the contracted work has 
been performed to the terms of their contract (performance-based payments are now the norm). 
Keeping contract records—such as progress reports, invoices, change records and payment records— 
is imperative and will be vital as evidence should a contract dispute or lawsuit arise. All too often, 
dealing with paperwork (and record-keeping in general) is left on the back burner in the haste to 
meet looming deadlines, but. this only creates major headaches later on when it comes time for final 
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documentation to be drawn up. It is for this reason that some organisations split the project Closing 
stage into two sub-stages: 


1. Clesure: This represents all the aspects of formal administrative project closure, minus any 
ongoing financial aspects of the project. This is where the ‘soft aspects’ of HR are managed, the 
project library is archived, the project closure reports are drafted and final sign-off is achieved. 


2. Finalisatien: Here, only the final accounting and invoicing aspects remain and these can be 
carried out without the expense of retaining the project team (and often the project manager), 
providing that the project has passed on all relevant outstanding invoices, schedules of payments, 
performance acceptance criteria, and any withholding arrangements, to the finance and contracts 
departments of the business. 


19.3.1 Creating the final project report 


The final project report summarises project performance and provides useful information for 
continuous improvement. Although the final report will be customised to your organisation, the 
content of the final report typically includes the following: an executive summary, a review and 
analysis, any recommendations, and lessons-learned. 

Executive summary: This summary simply highlights key findings and facts relating to the 
project’s implementation—whether or not the project objectives (and CSFs) were met for the customer. 
For example, are stakeholders satisfied that their strategic intents have been met? What has been 
user reaction to the quality of the deliverables? Are the project deliverables being used as intended, 
and providing the expected benefits? Final time, cost and scope performances are listed. Any major 
problems encountered and addressed are noted here, as are summaries of key lessons-learned. 

Review and analysis: Data is collected to record the project history, management performance, 
and lessons-learned, to improve future projects. Analysis examines in detail the underlying causes 
of problems, issues and successes. The analysis section includes a succinct, factual review of all 
dimensions of the project, for example, project CSFs, objectives, deliverables, the procedures and 
systems used, quality outcomes and organisational resources. It is common to collect data from both 
an organisational and project team viewpoint. The PM® or closure facilitators often use questionnaires 
and surveys to pick up on issues and events that need to be examined further. For example, ‘Was the 
organisational culture supportive and correct for this type of project? Why? Why not?’ or ‘Did the 
team have adequate access to organisational resources—people, budget, support groups, equipment?’ 
The project will also provide project schedules, cost comparisons, scope data and other data needed 
to tell the story of performance. The review and analysis should aim to cover all of the knowledge 
areas of scope, time, quality, cost, resources, communications and information, risk, procurement, 
stakeholders and integration. Without a full analysis of each area, there is potential to miss elements 
that may provide useful information for lessons-learned for future projects. When undertaking this 
analysis, the project manager must consider three questions (for each of the dimensions): 


1. What was planned? 
2. What was changed? 


3. What was delivered? 


Recemmendatiens: Usually, review recommendations represent. major improvement actions that. 
should take place. They can be technical in nature and focus on solutions to problems that surfaced. 
For example, to avoid rework, the report for a construction project may recommend shifting to a 
more resilient type of building material. In another situation, there may be a recommendation that. 
a vendor or contractor relationship be either terminated or sustained. 

Lessens-learned: Lessonslearned arguably offer the most valuable contribution to the closure 
process. Given the process evaluation and also the input gained from stakeholder meetings, it should 
be possible to set these out succinctly and clearly. The positive attributes of being able to empower 
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and inform others in future projects needs to be highlighted. In practice, new project teams looking 
for learning insights for a new project they are about to embark on find that studying past project 
reports (for projects that are similar to the project they are about to start) can reap valuable rewards. 
Team members frequently remark: ‘The recommendations were good, but. the “lessons-learned” 
section really helped us to avoid many pitfalls and made our project implementation smoother’. It 
is for precisely this reason that lessons-learned have taken on greater prominence in the project 
management field and warrant an extended discussion at the end of this chapter. Three key questions 
to ask when capturing lessons-learned are: 


1. What went well? 
2. What didn't go so well? 
3. What would we do differently next time? 


Lessons-learned are not just a one-off activity that is carried out at the end of the project. Although 
a formal lessens-learned werkshep is a planned activity that should be held at the end of the project 
(or stage), in modern project environments, it is also common to seek and exploit lessonsearned at 
team meetings, at reviews and during heath checks and audits throughout the life cycle of a project. 
See Snapshot from Practice: Gateway review lessons-learned. 


19.3.2 Other important closure activities 


Chapter 6 contains an integrated list activities for each knowledge area. In these lists are items relating 
to project closure. The reader is encouraged to review these items in conjunction with the following 
dot-points. 


SCOPE 


m Validation of what was preduced by the project to what was defined within the scope document, 
including any changes. This would include a review of the project's objectives, outcomes, outputs 
and benefits (i.e. you, as project manager, need to consider whether the project delivered what it 
promised to deliver). 


m A review of all changes requests to ensure the delivery of changed requirements took place and 
that there are no eutstanding requests. 


m Handing over any unapproved (or ‘phase 2 project’) ideas/change requests back to the business 
for consideration as an upgrade, or as a phase 2 project. 


æ Handover and sign-off of the projects deliverables to the relevant business owners. 


TIME 


@ Final project reporting: baseline (including approved change requests) versus actual schedule. 


m Checking to ensure that all work packages and tasks have been completed according to the 
project schedule. 


Æ Capture of scheduling (time-related) lessons-learned. 


COST 


@ Final project reporting: baseline (including approved change requests) versus actual budget. 


m Updating the organisation’s Enterprise Resource Planning (ERP) system, finance system and 
other systems as required, with details of the final project costs. 


=m Closing down access to IT systems to prevent any future projects from accidentally booking 
costs to the account. codes and work orders set up for this project. 
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QUALITY 


E Ensure all project and product/service quality outputs/outcomes have been achieved. 
BH @btain final quality signoffs, as required. 


@ Interact with suppliers on final defect lists, including withholding final payments related to these 
final defect lists. 


RESOURCES 


@ Closure celebration: this provides an opportunity for thanks and praise to be given as deserved 
and to celebrate the successes of the project. 


m Release of staff from the project (whether this be from a contract, allowing seconded staff to 
return to their substantive role, or otherwise). 


@ Final team and individual performance reviews. 
E Exit interviews. 


m Payment of retention and other bonuses, as agreed based on actual performance. 


COMMUNICATION AND INFORMATION 


Ææ Communicating the project’s success to all project stakeholders (and beyond, as appropriate). 
Note that this may require generating a number of different communication messages to the 
different groups of stakeholders of the project. 


m Final project status report(s). 


m Ensuring project documentation is updated within Project Management Information Systems 
(PMISs) or the project library, for example, prior to archiving the project library within the 
organisation’s Document Management System (DMS). 


RISK 


m Make sure the business is aware of any ‘open’ risks, by setting this out clearly in the handover 
documentation. 


Æ Report the final project Risk Register as part of the final project closure report. 
E Capture all lessons-learned related to the management of risk. 


m Review the risk management process for continuous improvement opportunities. 


PROCUREMENT 


E Final assessments to be made of contract deliverables based on the defined quality/acceptance 
criteria. 


m Agree on defect or fix lists and the payments to be withheld until such problems have been 
resolved. (@n a cautionary note, be aware that although standard percentages are usually agreed 
within a contract for such situations, if the monetary value of the defects exceeds the monetary 
percentage that has been withheld, it may be possible for the supplier to walk away from the 
contract by declaring bankruptcy.) 


m Hand over warranties and guarantees to the appropriate business owner. 


m Review the performance of all suppliers and contractors used in the project and notify the 
procurement and contracts departments of the outcomes of this assessment. Especially highlight 
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where performance has been subpar and where consideration therefore needs to be given to 


potentially net using those particular suppliers/contractors for future projects (subject to existing 


contractual tie-ins). 


m Final formal contract closeout activities (as defined in the organisation's policies and procedures). 


STAKEHOLDERS 


Relationships with stakeholders should have been left on a positive footing with the potential for 


repeat business being likely/possible. 


All stakeholders/stakeholder groups involved in the project have been thanked for their 


individual contributions. 


If a Customer Relationships Management (CRM) system was used by the project, then 
stakeholder information is returned to an appropriate business owner as ongoing organisational 


information. 


Any outstanding issues in relation to stakeholders are resolved or passed back into the business. 


19.4 PERFORMANCE EVALUATION 


Many activities around project closure support the process of reviewing what actually went on in the 


project. Performance reviews—of the project team, of the contribution made by each individual and 


the performance of suppliers and of contractors—all form components of the performance review 


SNAPSHOT FROM PRACTICE Gateway review lessons-learned 


Lessons-learned@ are often captured in a@ hoc project 
management documentation, orinthe heads of individuals, 
but more often, they are simply not captured ane are lost. 
Governments, as well as corporates ane small-to-medium 
enterprises, are becoming increasingly aware of the 
potential significance of losing such rich knowledge and 
information. They realise that not capturing, publishing 
ane passing this type of knowledge and information into 
the organisation for the benefit of future programs and 
projects represents a significant missed opportunity. 

The Australian Government (Department of Finance 
aned Deregulation) actively seeks to capture lessons- 
learned from projects via gateway reviews in a series of 
formal reports. In its Gateway Review Process—Lessons 
Learned Report (2011), the reasons stated for investing 
effort into publishing a formal lessons-learne@ report are 
given as: 


... to promulgate the lessons-learne@ and evidence 
of better practice observed from gateway reviews 
conducted during 2009-10, to assist agencies 
to identify opportunities for improving their own 
management of projects ane programs. Many 





of the projects reviewed during this period 
involved cross-government and multijurisdictional 
initiatives, which can be inherently more complex 
than single agency projects. This report presents 
lessons-learneal across four themes: 


m managing complex governance arrangements 
across agencies ane jurisdictions 


m project inception, gaining approval and 
funding 


m risks associated with implementing projects in 
tight timeframes; ane 


m establishing a ‘benefits-led’ approach. 


Project managers are increasingly looking to events 
of the past to inform events of the future. Formal lessons- 
learned may be found in publications, in lessons-learned 
databases and in centralised processes. The lessons that 
have been learned should be leveraged in future project 
environments, to ensure (often expensive) mistakes and 
misse opportunities are not ignored. 
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and closure stage of the project. Note that some of these aspects will have already been considered 
(planned for) during HR activity planning (set out in Chapter 13) and these are discussed further in this 
section. ®ther aspects, such as contractor performance, were introduced in Chapter 18; concluding 
discussion on their performance is provided in this next section. 


19.4.1 Post-implementation review (PIR) 


The purpose of a project closure report is to capture the facts of the project, whereas the purpose of a 
PIR is to assess how well the project, the project team, and the project manager perfermed. PIRs are 
often carried out by a person who is external to the actual project (e.g. they may work for the PM@). 
The timing of a PIR is critical as the aim is to capture knewledge from people on the project, but of 
course if these people have already left the project, the value in carrying out. a PIR will be somewhat 
diluted. When conducting the review: 


E Ask fer epenness: Some aspects of the project might not have gone as expected, but these are 
often where greater learnings take place. 


E Be ebjective: Avoid emotions and politics; stick to the documented facts. 


E Be future-fecused: Remember that although we can look back with hindsight, we are capturing 
lessons for future projects. 


E Beth pesitive and negative perspectives: Both perspectives are equally important. at this stage 
in the review. A simple technique for gaining quick responses is the ‘3 + 3’ questionnaire, where 
stakeholders are asked to list three positive and three negative aspects of the project. The 
technique gives equal weight to both positive and negative aspects (it is too easy otherwise to 
focus on negative aspects rather than positive ones). 


A PIR interview and subsequent data/information analysis (leading to the final PIR report) will 
typically cover the following areas: 


E Gap analysis: What was originally defined? What was actually delivered? What. got changed on 
the way? 


E Determinatien ef the achievement ef the pre ject geals: Did the product/service delivered meet 
the requirements that were originally defined? Were these to the quality defined? And ultimately, 
was it what the customer wanted? 


E Stakehelder satisfactien: Were the stakeholders satisfied with the behavioural aspects of the 
project manager's and team’s performance as well as with what was delivered? 


m Benefit review: If benefits were to be delivered as part of the project, have these been checked? 
What benefits are still to be realised by the business and who in the business is going to take 
accountability for bringing them to fruition? 


E Areas identified fer further develepment: These could relate to the project management 
methodology or other organisational process assets. 


E Lessens learned: Are there wider lessons for the organisation that go beyond the project 
perspective? 


19.4.2 Team evaluation 


The evaluation of team performance is essential for encouraging positive changes in behaviour 
and to support individual career development. and continuous improvement. (e.g. through inhouse 
organisational learning processes or via individual sponsorship to undertake external training). 
‘Evaluation’ implies measurement against specific criteria. Experience proves that the stage for 
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evaluation must be set befere the project commences: the expectations and standards to be met need 
to be Knewn (so too, do any constraints) and a supportive organisational culture needs to be in place. 
If this isn’t the case, the effectiveness of the evaluation process will suffer. 


In a macro sense, evidence suggests that performance evaluation is often not performed well; the 


major reasons cited by practitioners being twofold: 


L 


Evaluations of individuals are left to be carried out by the team member’s own home department 
supervisor(s). 


Typical measures of team performance centre on time, cost and specifications. 


Most organisations do not go beyond these measures, although they are important and critical. 


@rganisations should therefore consider evaluating the team-building process, the effectiveness of 
group decision and problem-solving processes, group cohesion, evaluating the level of trust among 
team members, and the quality of information that was exchanged. Measurement of customer and user 


satisfaction with project deliverables (i.e. the project results) is often missed completely. Yet, project 
success depends significantly on satisfying these important factors. The quality of the deliverables is 
the responsibility of the team. 


In order to be in a position to be able to carry out an evaluation of the project’s team performance, 


it will be necessary to first define the criteria against which they will be evaluated. This process was 
outlined in Chapter 14, and is further discussed below: 


1. 


Sg or 


Do standards for measuring performance exist? Peter Drucker was once quoted as saying, ‘You 
can’t manage what you can't measure’. It is important therefore to be able to assess whether 

the goals (and the expected targets for these goals) were made clear for both the team and the 
individuals within the team. Were they challenging? Were they attainable and attained? Did they 
lead to positive consequences? 

Are individual and team responsibilities and performance standards known by all team members? 


Are team rewards adequate? Do they send a clear signal that. senior management believes that the 
synergy of teams is important? 


Is a clear career path for successful project managers in place? 
Was the team empowered to manage short-term difficulties? 
Is there a relatively high level of trust emanating from the organisational culture? 


Team evaluation should go beyond time, cost and specifications. Are there criteria beyond 
the constraint criteria? Creation of project deliverables would be a good place to start. The 
‘characteristics of highly effective teams’ discussed in Chapter 14 can easily be adapted as 
measurements of team performance. 


What organisational learning can be taken away from the process of team and individual 
performance management? Was this fed back into the relevant areas of the business (e.g. to the 
HR department and/or the line manager?) 


In practice, the team evaluation process takes many forms—especially when evaluation goes 


beyond time, budget and specifications. A typical mechanism for the evaluation of teams is a survey 
administered by the HR department. The survey is normally restricted to team members, but in some 
cases, other project stakeholders interacting with the team may be included also. Asample of a survey 
can be seen in Table 19.3. After the survey results have been tabulated, the team will meet with the 
facilitator and/or senior management to review the results. 


This session is comparable to the team-building sessions that were described in Chapter 14, except 


that the focus here is on using the survey results to assess the development of the team, its strengths 
and weaknesses, and the lessons that can be applied to future project work. The results of team 
evaluation surveys are helpful in changing behaviour to better support team communication, the team 


approach, and a continuous improvement of team performance. 
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Table 19.3 Sample team evaluation and feedback survey 


. Did the team share a sense of common purpose? 

. Was each member willing to work towards achieving the project’s objectives? 
Was respect shown for other points of view and ideas? 

. Were differences of opinion encouraged and freely expressed? 

Was it possible to achieve consensus on project decisions, in the main? 


. Did the majority of interactions among team members occur in a comfortable, open, 
honest and supportive atmosphere? 


7. Were all project meetings properly managed and run effectively? 
8. Did the team’s communication methods and the frequency and content of communications 
meet your personal needs? 


9. Were project tasks shared equally within the project team and were the skills of individuals 
leveraged in an effective manner? 


Au WNR 


10. Was working on the team project a valuable experience for you? 
41. Did you learn new skills and/or gain beneficial experience by being involved in this project? 


12. Did your supervisor display empathy and were they able to listen to your concerns and 
ideas? 


13. Were you able to speak freely with your supervisor, even if you disagreed with the 
decisions being made? 


14. Was the feedback on your performance accurate, timely and constructive? 
15. Did you feel you were a member of a well-functioning, co-operative team? 


16. Did the project management environment employ a continuous improvement process that 
improved the process and procedures of the project? 


17. Did you clearly understand the needs of the customer and did the project reflect these 
needs? 


18. Were you able to inform other people that you were proud to be working on this project? 


19. Were you able to achieve an overall balance between the project's requirements and your 
personal life? 


19.4.3 Performance reviews 


@rganisations vary in the extent to which their project managers will be actively involved in the 
appraisal process of team members. In organisations where projects are managed within a functional 
organisation, the team member's area manager, not the project manager, will be responsible for 
assessing performance. The area manager may solicit the project manager's opinion about the 
individual’s performance on a specific project; this will be factored into the individual’s overall 
performance. In a balanced matrix, the project manager and the functional manager will jeintly 
evaluate an individual's performance. In a project matrix and for project organisations in which the 
lion’s share of the individual’s work is projectrelated, the project manager will be responsible for 
appraising their individual performance. ®ne process that appears to be gaining wider acceptance is 
the multi-rater appraisal or 360-degree feedback, which involves soliciting feedback concerning a 
team member's performance from everyone their work affects. This would include therefore not only 
project and functional managers, but also peers, subordinates and even customers. Refer to Chapter 
14 for further details on perfermance and feedback. 

Performance appraisals generally fulfil two important functions. The first is developmental in 
nature; the focus is on identifying individual strengths and weaknesses and developing action plans 
for improving performance. The second is evaluative and involves assessing how well the person 
has perfermed in order to determine salary or merit adjustments. These two functions are not 
compatible. Employees, in their eagerness to find out how much pay they will receive, tend to tune 
out constructive feedback on how they can improve their performance. Likewise, managers tend 
to be more concerned with justifying their decision than engaging in a meaningful discussion about. 
how the employee can improve their performance. It is difficult to be both a coach and a judge. 
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As a result, several experts on performance appraisal systems recommend that organisations 
separate performance reviews (which focus on individual improvement) and pay reviews (which 
allocate the distribution of rewards). 

In some matrix organisations, project managers conduct the performance reviews, while the area 
managers are responsible for carrying out pay reviews. In other cases, performance reviews will 
be part of the project closure process, with pay reviews being the primary objective of the annual 
performance appraisal. @ther organisations avoid this dilemma by allocating only greup rewards for 
project work and provide annual incentive awards for individual performance (such as shares and 
bonus payment). 

The remaining discussion is directed at reviews that are designed to improve perfermance, because 
pay reviews are often outside the project manager's jurisdiction. 


INDIVIDUAL REVIEWS 


@rganisations employ a wide range of methods to review the performance of individuals working on 
a project. In general, the review methods used to assess individual performance tend to centre on the 
technical and social skills an individual has brought to the project and to the team. Some organisations 
rely simply on an informal discussion between the project manager and the project member. @ther 
organisations may require project managers to submit written evaluations that describe and assess 
the individual's performance on a project. Many organisations use rating scales that are similar to a 
team evaluation survey; the project manager rates the individual according to a certain scale (e.g. 
from 1 to 5) on a number of relevant performance dimensions (e.g. teamwork, customer relations, 
communication). Some organisations augment these rating schemes with behaviourally anchored 
descriptions of what constitutes a ‘1 rating’, a ‘2 rating’ and so forth. Each method has its strengths and 
weaknesses and unfortunately, in many organisations, the appraisal systems are designed to support 
mainstream operations, and not unique project work. The bottom line is that project managers have to 
use the performance review system that is mandated by their organisation as best they can. 

Regardless of the method used: the project manager needs to sit down with each team member 
and discuss their individual performance both at the outset of the project and periodically throughout 
the project, as well as at project closure. The following list offers some general tips for conducting 
performance reviews (but of course project managers must use their own discretion, according to 
their organisation’s requirements): 


m Always begin the precess by asking the individual te evaluate their centributien te the preject: 
First, this approach may yield valuable information that you were not aware of before. Second, 
this approach may provide an early warning for situations in which disparity exists between 
assessments. Third, this method helps to reduce the judgemental nature of discussions as it 
fosters a balanced and open dialogue. 


E Aveid (where pessible) drawing cemparisens with ether team members: Instead, assess the 
individual in terms of established standards and expectations. Comparisons tend to undermine 
cohesion and divert attention away from what the individual needs to do to improve their 
performance. 


E When yeu have te be critical, fecus the criticism en specific examples ef behavieur, rather 
than en the individual persenally (make sure you have gathered the facts prior to the meeting). 
Describe in specific terms how the behaviour affected the project. 


E Be censistent and fair in yeur treatment ef all team members: Nothing breeds resentment more 
than if individuals feel (or hear through the grapevine) that they are being held to a different 
standard than other project members. 


E Treat the review as enly ene peint in an engeing precess: Use it to reach an agreement as to hew 
the individual can improve their performance. 
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Managers and subordinates alike may dread a formal performance review. Neither may feel 
comfortable with the evaluative nature of the discussion that is to take place and the potential for 
misunderstandings and hurt feelings to arise. Much of this anxiety can be alleviated if the project 
manager is doing their own job well: project managers should constantly be giving team members 
feedback throughout the project so individual team members already have a pretty good idea of how 
well they are/or have performed and how the manager therefore feels before the formal meeting. Post- 
project angst can be avoided if pre-project expectations are discussed before the project starts and 
are regularly reinforced during project performance. 

While in many cases, the same process used for reviewing the performance of team members 
will also be applied to an evaluation of the project manager's performance, many organisations will 
augment this process (given the importance of the project manager's position to their organisation). 
This is where the 360degree review is becoming increasingly popular. In project-driven organisations, 
the PM® will typically be responsible for collecting information from customers, vendors, team 
members, peers and other managers about a specific project manager's performance and approach. 
This methodology offers tremendous potential for helping to foster the development of more effective 
project managers if done well. 

As well as data being generated for (and by) performance reviews, data can also be collated to 
inform lessons-learned. 


19.4.4 Contractor and supplier evaluation 


As well as assessing team and individual performance, it is important to review the performance of 
centracters and suppliers. Contractors may be subject to similar types of review processes, but the 
way in which the gathered information is used will vary according to the maturity of the organisation. 
It is important to capture information about good and poor performances by contractors and 
suppliers: it is very easy for this knowledge to be lost when the project closes. Who this information 
ought to be shared with within the organisation needs careful consideration: reflect on what some 
of the implications of net sharing this information might be (e.g. re-employing under-performing 
contractors, using suppliers that didn’t perform to requirements). 

Contractors often work as individuals, making it relatively easy to capture information about their 
performance. However, there must be a clear understanding of whose responsibility it is to inform the 
HR department about both good and poor performance. The project manager might be asked to make 
recommendations about who to use for future projects (and who it might be advisable to avoid in the 
future). 

Good contractors should be documented as being suitable for work on future projects. This 
type of information can be both practical and useful, since contractors may not have specific HR 
records within the organisation and therefore, from a procurement perspective, might be viewed as 
(just) another contract that has been established and closed. Many organisations that regularly use 
contracted resources are increasingly realising the benefits of holding registers of appreved (tried 
and tested) contractors and consultants (often populated with details of their past performance 
also). A project manager therefore potentially will have a rich repository readily available to them, 
to assist them with decision-making. Note: Government organisations in Australia are subject to 
the Freedem ef Infermatien Act 1982 (Cwlth) and contractors may have a legal right to check the 
information held about them and to ask for any incorrect information to be rectified or removed from 
such registers. 

Supplier perfermance should also be reviewed. Supplier performance can make or break a 
project, especially when their commitment to the project is against critical project activities. All 
suppliers should therefore be reviewed. Sample review criteria are demonstrated in Table 19.4. 
Note: In some organisations, the contract and procurement departments will already have a 
predefined supplier survey for the project manager to complete. As project manager, you will 
therefore need to check this. 
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Table 19.4 Supplier performance review 

Timeliness of deliveries/service provided 

Completeness of deliveries/service provided 

Non-agreed changes to product/service specifications 

Met all contract terms and conditions 

Friendliness of service and support 

Ability and willingness to correct defects in a timely manner 
Recommended to give repeat business 

Provided status and tracking information required by the project 

Quality of product/service was consistent with agreed quality requirements 
Ability to accommodate changes to requirements, in line with project change requests. 


‘Total score = Weight x Score 


Source: @ 2018 Dr Neil Pearson 


Each criterion shown in Table 19.4 (and others your organisation deems necessary) should be 
reviewed against a set of predefined scores (this ensures an ‘apples-with-apples’ comparison of 
suppliers can be made later on, rather than risking an ‘apples-with-oranges’ comparison). For example: 


Unsatisfactery: Fails to react or respond/deliver in timely manner. 
Fair: ®ccasionally fails to react or respond/deliver in timely manner. 
Satisfactery: Acts and responds to agreed parameters. 


Geed: Acts or responds/delivers in timely manner above agreed parameters. 


Outstanding: Continually acts or responds/delivers in timely manner, exceeding all expectations. 


@nce supplier reviews have been completed, the project manager must ensure the performance 
feedback is disseminated to all appropriate departments within the organisation. Be sure to notify the 


contracts and procurement. department and the finance department as this will enable a permanent 
track record to be created, so when future projects come along the benefits of hindsight will be readily 
available. 





19.5 LESSONS-LEARNED 


Lessons-learned represent analysis that is carried out during the project and at the project Closing 
stage. Lessons-learned attempt to capture both positive and negative project learnings (i.e. what 
has been gleaned). This analysis considers ‘what worked and what didn’t?’ Lessons- learned (or ‘post 
mortems’, ‘post-project reviews’ or whatever name your organisation chooses to use) have long been 
part of the project management approach. Peter Senge’s The Fifth Discipline: The Art and Practice 
ef the Learning Organisatien (1990) drew focus towards the institutionalisation of organisational 
learning. Figure 19.3 illustrates a typical lessonslearned process. 

Although analyses of past processes often prove to be useful for closure and lessons-learmed, it 
is true to say that often, their real value is not fully leveraged. Large, multinational companies with 
projects spread across the globe can find it challenging to effectively mine captured lessons-learned. 
Smaller organisations have also commented that they sometimes struggle to reap the potential 
rewards to be gained by examining lessonsleamed. The same project mistakes therefore tend to 
continue year after year, project after project. In the words of one executive: ‘Lessons-learned are 
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Figure 19.3 Le: 
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Source: ® 2018 Dr Neil Pearson 


worth their weight in gold! I do not understand why we don't do a better job nurturing, dispersing and 
implementing lessons-learned though’. Processes for capturing lessons-learned continue to evolve, but. 
countless practitioners acknowledge the existence of many types of barriers that can hinder or block 
the effective mining of lessons-learned. A few of the most ubiquitous barriers are noted below. 


E Lack of time to capture. 


= Most lessons-learned are captured when the project is complete; teams get little direction or 
support after the lessons are reported. 


 Lessons-learned often degenerate into blame sessions that became emotionally damaging. 
 Lessons-learned are not being used across different locations. 


E Lessons-learned while implementing the project are seldom used to improve the remaining work 
in the project. 


Too often, the lessons-learned are not used in future projects because the organisational culture 
fails to recognise the value of learning. 


What is needed to overcome these barriers is a strong methodology and management philosophy 
to ensure lessons-learned are identified, recorded, utilised and become a significant part of the project 
and organisational culture. The key is to turn lessons-learned into actiens and to have semeene ewn 
the lessen. The military has long used lessons-learned to improve their operations (e.g. after each 
manoeuvre has taken place). Lessons-learned have emerged as a strong process and management. 
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philosophy and is used by projectdriven organisations around the world to mine the gold that 
lessons-learned can reveal. Lessons-learned are championed by Norman Kerth in his text: Pre ject 
Retrespectives (2001) as follows: 


A retrespective is a methedelegy that analyses a past preject event te determine what werked 
and what didn’t, develeps lessens learned and creates an actien plan that ensures lessens 
learned are used te impreve management ef future prejects. 


The key point in conducting lessons-learned analyses is to reuse selutiens and to step repetitive 
mistakes. A well-run lessons-learned workshop should have several embedded, distinguishing 
characteristics to help ensure its effectiveness and value. For example: 


E It should be run by an independent facilitator. 
It should include a minimum ef three ‘inprocess’ learning gates during the project life cycle. 
The workshop has an owner. 


A repository that is easy to access and use is developed. 


Discipline is mandated to ensure lessons are reviewed and used in future projects. 


19.5.1 Initiating the review 


The review precess style depends primarily on organisational and project size. Every effort should 
be made to make a project review a normal process rather than a surprise occurrence. In small 
organisations and projects where face-to-face contact at all levels is prevalent, project closure may be 
an informal process and simply take the format of a staff meeting. But even in such an environment, 
the content of a formal project review should still be examined and covered, and notes should be made 
of the lessons that have been learned. In some organisations, review initiation comes from a formal 
project review group, or this can be automatic. With the latter, for example, all projects are reviewed 
at specific stages in the project life cycle—i.e. perhaps when a project is 10 to 20 per cent complete 
in time or money or when it is 50 per cent complete, and after its completion. In most multi-project 
organisations, reviews (called gates) will be planned for the completion of major milestones. These 
types of reviews are not linked to per cent complete as milestones are binary; either the requirements 
for completion have been reached, or they have not. It is important to emphasise that regardless of hew 
reviews are set up, they need to be set up in the project Planning stage (i.e. befere the project begins). 


19.5.2 Use of an independent facilitator 


Project managers should consider using an independent facilitator to collect and implement lessons- 
learned, as these can potentially help to improve the management of current and future projects. A 
facilitater is a guide who leads the project team through an analysis of project activities: those that 
went well, and those that require improvement or replacement. The facilitator develops a follow-up 
action plan that. clearly sets out defined goals and also accountability (‘who is responsible for what 
and by when’). 


CHARACTERISTICS OF A FACILITATOR 


All project reviews will necessitate deciding whe will facilitate and who will be accountable for 
conducting the review. Perhaps nothing influences the success of a project review more than the 
selection of the closure facilitator. This person should not be randomly chosen from personnel in 
the PM®. Independence is key when selecting the facilitator, therefore at minimum, they should: 


1. Have no direct involvement or direct interest in the project. 


2. Be perceived as impartial and fair. 
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go 


Have the respect of senior management and other project stakeholders. 


E 


Demonstrate willingness to listen. 


a 


Exhibit independence and the authority to confidently report review results, without bowing to 
recriminations and complaints from vested interests. 


Have the best interests of the organisation at the forefront when making decisions. 


Have proven robust experience of working in the organisation or industry. 


ROLES OF A FACILITATOR 


There are good reasons for using an independent facilitator. Lessons-learned exercises can sometimes 
degenerate into griping sessions where blame is bandied about and individuals may feel attacked 
about their performance on the project. This can result in poor, guarded participation. When this 
happens, the focus strays away from concentrating on root causes and how to improve performance 
in future projects and lists sideways into mudslinging boggy waters. The facilitator therefore needs to 
be careful to avoid blame and to ensure others also do not apportion blame. In this way, stakeholders 
can feel safe to provide input in an open and honest, constructive manner. 

A trained independent facilitator is often capable of eliciting information that would not be 
forthcoming to the project manager. Project participants report they are far more willing to attend 
and contribute to a lessonslearned session run by an independent facilitator who can often eliminate 
many political aspects of discussions that would otherwise hinder the process. Another advantage 
of using an independent facilitator is that they can deliver any bad news to the project sponsor or to 
senior management, without fear of recriminations. 


19.5.3 Managing a review 


Having a facilitator available at the start of a project is the preferred situation to be in. This is because 
the lessons-learned approach stresses that lessons learned during project execution should be gathered 
and then applied to change remaining work. If lessons-learned are not captured early on, they may 
be lost; after all, people forget things, people leave the project etc. Capturing lessons midway through 
the project life cycle allows the way the remaining work is performed to be changed (note that some 
practitioners call this process ‘correcting course while the project is in flight’). Most lessons-learned 
methods use a minimum of three gates during the project life cycle. In this way, the lessons-learned 
can be applied to self-correct for the remainder of the project's execution (refer back to Figure 19.3). 

It is critical to have a separate repository or library, where reports and lessons-learned can easily 
be accessed and retrieved. The responsibility for maintaining a repository for lessons-learned and 
encouraging its use is normally the responsibility of the project office or oversight committee. It is 
not unknown however for a brilliant closure report to be created, only for it to be placed in someone's 
dusty filing cabinet (instead of in a repository or library), never to be seen again! This is truly a big 
mistake! Lessons-learned are often the single best source of information a project manager or team 
can use when planning a future project. Repeatedly, project managers recount how lessons-learned 
have saved their lives by allowing them to avoid a pitfall. Presentations at organisational meetings 
or conferences repeatedly encourage others to use and develop lessons that have been learned. (The 
sharing of lessons-learned may even provide an opportunity for the project manager to shine in front 
of senior management.) 


19.5.4 Overseeing a post-project review 

In the past, lessons-learned were primarily collected from a postproject survey. Someone reviewed 
the answers, summarised the results and filed the document. A lessons-learned facilitator will 
often use several questionnaires as a starting peint for conducting a post-project lessons-learned 
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analysis. These surveys often offer clues into previously unrecognised, deeper problems. 
A facilitator relates each clue to areas needing improvement, which are often found by checking 
the changes running through the project’s change request process. The hard data may point directly 
to areas that can be improved. In some cases, the data directs the facilitator to the area where a 
problem was selved. 


PROCESS AND METHODS REVIEW 


A process review begins with a review of the strategic intent of the project, the selection criteria, 
the Project Charter, the project objectives, project scope and the acceptance criteria. This starting 
point reinforces and clarifies the Business Case for the project and the final project deliverables. 
Additional data gathering for the process review is initiated through a questionnaire distributed to all 
major project stakeholders for their response. Examples of some typical questionnaire questions are 
provided in Table 19.5 and although this sample questionnaire has some areas of omission, it could be 
used asa starting point for your own project. 


Table 19.5 Project process review questionnaire 


Question Yes/no/comment 


1. Were the project objectives and strategic intent of the project clearly and explicitly 
communicated? 


. Were the objectives and strategy in alignment? 

. Were the stakeholders identified and included in the planning? 
. Were project resources adequate for this project? 

. Were people with the right skillsets assigned to this project? 

. Were time estimates reasonable and achievable? 


NOOB WHN 


. Were the risks for the project appropriately identified and assessed before the project 
started? 


8. Were the processes and practices appropriate for this type of project? Should projects of 
a similar size and type use these systems? Why/why not? 


9. Did outside contractors perform as expected? Explain. 

10. Were communication methods appropriate and adequate among all stakeholders? Explain. 
11. Is the customer satisfied with the project product? 

12. Are the customers using the project deliverables as intended? Are they satisfied? 

13. Were the project objectives met? 

14. Are the stakeholders satisfied their strategic intents have been met? 


15. Has the customer or sponsor accepted a formal statement that the terms of the Project 
Charter and scope have been met? 


16. Were schedule, budget and scope standards met? 


17. Is there any one, important, area that needs to be reviewed and improved upon? Can you 
identify the cause? 


18. Were the project's deliverables (outputs and outcomes), benefits and objectives achieved? 


ORGANISATIONAL REVIEW 


@ne of the themes of this text is that project performance is strongly influenced by organisational 
culture. It is therefore important to be able to assess what fundamental organisational cultural 
properties exist that have the potential to affect your project’s success or failure, and/or which may 
become a hindrance to the project team. Again, survey questionnaires are easy, quick and somewhat 
inexpensive to develop in order to collect data expeditiously. Table 19.6 shows a partial organisational 
survey as found in practice. 

It is rare that important problems or successes will not show up in answers to a well-developed 
questionnaire. With the survey information in hand, the facilitator will carry out one-on-one visits to 
project team members, the project manager and other stakeholders to dive deeper into an analysis 
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Table 19.6 @rganisational review questionnaire 


Question Yes/no/comment 


1. Was the organisational culture supportive for this type of project? 


2. Was senior management support adequate? 

3. Were people with the right skills assigned to this project? 

4. Did the project office help or hinder management of the project? Explain. 

5. Did the team have access to organisational resources (people, funds, equipment)? 
6. Was training for this project adequate? Explain. 

7. Were lessons-learned from earlier projects useful? Why? Where? 

8. Did the project have a clear link to organisational objectives? Explain. 

9. Were project staff properly reassigned? 
10. Was the HR department helpful in finding new assignments? Comment. 


of cause-and-effect impacts. Fundamentally, the attempt is to isolate whether ‘a lack of x resulted in 
y’. It is important to stay with the big lessons. For example, the facilitator might ask team members: 
‘What was the biggest painpoint in the project?’ and from the responses given they can then synthesise 
the collective wisdom. 

Armed with the information gleaned from one-on-one sessions and from other sources, the 
facilitator can next lead a team lessons-learned session. This type of session usually starts with a 
review (synopsis) of the facilitator’s report and an attempt to elicit further (key) information from 
team members about any issues, stumbling points or contentions. In fact, one of the roles of the 
facilitator is to lead the team in exploring new ways for solving a problem. @nce the team reaches 
consensus about key lessons-learned, it next works together to develop and document an Action Plan 
for improving future projects. Each lessonlearned should have at least one lesson that will improve 
current or future projects. ®ne person needs to be assigned as the owner of the lesson and they will 
also serve as the go-to person if more information is needed. If possible, the facilitator should elicit 
senior management's commitment for implementing the lesson. 

A switched-on facilitator will also review archived lessons so they can investigate whether there 
have been any noticeable trends across similar projects: for example, they may consider whether 
there are affinities between problems and successes among many projects. They will also want to 
know whether resources have been inadequate or whether there is evidence that senior management 
has supported the mining of lessons-learned, and they may also look for any fundamental 
organisational culture dimensions that affected project successes and failures, or that became a 
hindrance to project teams. 

During a conversation with one PM® manager, it emerged that a facilitator had discovered (quitean 
obvious) problem that had been occurring fer ever feur years across most of the organisation’s multi- 
ceuntry projects. It is difficult. to believe that no one picked up on a problem that was detrimentally 
affecting so many of the organisation’s projects. In this American organisation, managers were 
simply too focused on schedules, performance and the bottom line. They neglected to establish a 
personal professional working relationship with their foreign counterparts—for example, they didn't 
ask about their counterpart’s key interests, their family, and cultural aspects that were important to 
them. Relationships were often strained and performance suffered. The outcome of the facilitator’s 
input was that. project participants in each country are now required to attend a cultural awareness 
class to learn about their counterpart’s country, customs and culture and project results have already 
improved dramatically. 


19.5.5 Utilisation of lessons-learned 


Each lesson-learned is assigned an owner (who is typically a team member who is interested in, and 
familiar with, the lesson-learned). This team member/owner serves as the contact point for anyone 
needing information (expertise, contacts, templates, etc.) relating to the lesson-learned. 
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The facilitator is also tasked with the job of ensuring there is a clear process in place to ensure 
lessons are used to improve the management of future projects. Some organisations mandate that the 
team allocated to a new project must review the lessons-learned on similar, past projects. This mandate 
tactically ensures that the most significant lessons are institutionalised: there will be no future excuse 
for not having used past best practices and for not having avoided past mistakes. If previous project 
managers (before your project) have completed lessons more effectively, your project might have 
avoided many mistakes. @f course, a requirement is archiving the lessons in a repository/library. But 
beyond a lessons-learned library, a simple, easy to use, consistent format is necessary to ensure that 
information is easily found, used and updated over time. A blog can be used to receive user comments 
on how helpful the lesson is in improving a process or product. 


19.5.6 Archiving lessons 


If lessons-learned are to be used effectively, it is critical to have some type of a repository (or library) 
in place where reports and lessons-learned can be deposited, accessed and easily retrieved. This is 
especially relevant in today's global marketplace where the majority of globally present. businesses 
will use some version of a webbased system (e.g. Basecamp, SharePoint, Trello) to facilitate 
the sharing of information and to archive shared learning. The responsibility of maintaining and 
promoting a repository of lessons-learned is normally the responsibility of the project office or 
oversight committee. Usage of such a repository often depends on how easy it is to search for relevant 
information. Personnel will be discouraged from accessing the repository if information is difficult to 
find. For example, one project manager commented: ‘There are so many lessons-learned items in the 
library, I can't find information that applies to my project!’ At a minimum, the repository should classify 
projects by ‘type’ or ‘characteristics’. Each project review is categorised because there are differences 
in the way projects with different characteristics are managed and handled in an organisation. The 
classification of projects by characteristics allows prospective readers, teams and project managers 
to be selective in their search and use of report content. 

A snapshot of part of a repository classification scheme that allows prospective project 
stakeholders to start their search for information, related to their prospective project might show: 


Project type (e.g. development, marketing, systems, construction) 
Size (e.g. monetary, duration) 

Number of staff 

Technology level (e.g. low, medium, high, new) 

Strategic or operational support 


Product, service or hybrid 


Make (develop internally) or buy (outsource). 


Many other classification fields relevant to the organisation could be included so users can drill 
further down into the repository to search for projects which match the features of their prospective 
project. 


19.5.7 Concluding notes: Lessons-learned 


The impetus for the success of lessons-learned has been increasing recognition of the real value of 
lessons-learned in improving the management of future projects. For example, Intel, which has project 
teams dispersed over 290 locations in 45 countries, has found the use of trained facilitators to be 
highly effective in the process of mining and using lessons-learned. Intel continues to train 15 new 
facilitators each year. The lessons-learned approach is now standard operating procedure in many 
project-driven organisations. The lessons-learned are often the single best source of information a 
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project manager or team can use in planning their next project. Lessons-learned are a main change 
agent for developing best project management practices across an organisation. The lessons-learned 
approach represents a positive step towards ensuring lessons are both developed and implemented so 
that the efficiency and efficacy of future projects is improved. 
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Figure 19.4 


19.6 BENEFITS REALISATION 


An emphasis on the delivery of value from project investments is (thankfully) trending upwards in 
the project management industry. Value (or the benefits to be realised) are rapidly becoming a 
project manager's area of responsibility and accountability. This is evident if the reader refers back 
to Chapter 2, where a number of project management approaches were introduced, including APM, 
Praxis® and IS@2100:500. Most of these project management approaches included activities to not only 
identify (pre-project or at. project start-up) benefits, but also to realise benefits at preject clesure and 
handever benefits beyend the project to the business. Figure 19.4 illustrates a benefits management 
process across the Preject Management Bedy ef Knewledge (PMB@K) (PMI 2017) project management. 
life cycle. 
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Figure 19.4 indicates two key activities that occur at project closure in relation to benefits. It is 
important to: 


1. Ensure that all planned benefits, as stated at the project's outset, are accounted for and delivered 
at project closure. This would include any adjustments to the benefits that may have been agreed 
and approved at the various project gateway reviews. Measuring and reviewing benefits is no 
trivial activity and really draws on the project manager's ethics for them to be open, honest and 
transparent when declaring what benefits have been delivered against what was declared at the 
start of the project and adjusted at the gates throughout the project. 


2. Ensure that benefits that go beyond the project are handed over to an accountable business 
owner for later realisation in the business. The project manager must ensure that the benefit is 
properly documented, communicated and handed over to the accountable business owner, ina 
professional manner. 


As with all project tasks, these activities must be planned in advance and should be included 
in the projects schedule, budget, and in relevant stakeholder and communication documents. The 
Business Case, for example, would be updated and (more often in today’s modern pro ject management 
organisations) a Benefits Realisation Plan would be prepared for presentation and handover to the 
business. Benefits management is a growing area of project management; therefore, the authors 
recommend reviewing this chapter’s Weblinks to discover further material on this subject. 


19.7 PROJECT CELEBRATION 


The final closure activity for the project manager will be Figure 19.5 Project team thank you and celeb 
the project's closure celebration! Hopefully this will be an 
upbeat, jovial get-together offering a chance to celebrate 
successes, bring closure, and act as an opportunity for good 
byes to be said. This celebration is an opportunity to recognise 
the efforts that project stakeholders have contributed. Even 
if the project did not reach its objectives 100 per cent, it is 
still appropriate to recognise the effort and goals that were 
achieved. If the project was a success, invite everyone who, 
in some way, contributed to project's success. Thank the 
team as a group and also thank each person individually. 
The spirit of the celebration should be one in which the 
stakeholders are thanked for a job well done and from which 
they leave with a positive feeling of accomplishment. 


The goals of project closure are twofold: 


1. To complete the project and carry out a final handover to the business. 
2. To inform the improvement of future projects. 


Closure has three major components: 


1. Key project closure activities: Wrap-up activities include delivering the final project deliverable(s), closing 
accounts, finding new opportunities for project staff, closing facilities and creating the final report. 
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2. To carry out a performance evaluation: Project evaluation verifies and documents project performance and team and 
individual performance in order to manage staff members and their contribution(s) and also supplier and contractor 
performance, in order to inform the organisation about good and poor performers. 


w 


To capture lessons-learned: Ensuring lessons-learned are identified and are used. Too often we spend massive 
amount of dollars planning a project but little to nothing learning from the experience of completing the project. 
Failure to review, assess and record project successes and failures has consistently proven to be a costly waste. The 
lessons-learned approach seeks to obviate this waste. 


Project closure is both a happy and sad time! It is where we celebrate the success of the project, but also where we 


say our goodbyes to people we have worked with, for (often) extended periods of time. The project manager must 
ensure that every person is thanked for their contribution before closing the doors on the project. 


https://ivm.org.uk/benefits-and-rewards-of-value-management 
https://www.axelos.com/news/blogs/september-201 7/benefits-realization-value-project-management 
https://www.pmi.org/learning/library/strategic-value-management-business-benefits-8699 
http://www.stephenjenner.com/free-materials/ 
https://hbr.org/2016/06/a-tool-to-map-your-next-digital-initiative 


360-degree feedback deliverable acceptance project archive 

benefits realisation final project report project celebration 

Benefits Realisation Plan lessons-learned (retrospectives) project closure 

Business Case Lessons-Learned Register project closure report/meeting 
closure activities performance reviews team evaluation 

contractor and supplier evaluation post-implementation review (PIR) 


Review questions 


1. How does the project closure review differ from the performance measurement control system, discussed in 
Chapter 11? 


2. What types of information would you expect to find in a post-implementation review (PIR)? 
3. Why is it difficult to perform a truly independent, objective review? 


4. Comment on the following statement: ‘We cannot afford to terminate the project now. We have 
already spent more than 50 per cent of the project budget’. 


5. Why should a project manager separate performance reviews from pay reviews? How do you do this? 
6. Why is it important to review supplier and contractor performance? 
7. Explain the activities in relation to benefits that occur across the project life cycle. 


4. Taking the project closure checklist (refer to Table 19.2) review, and add in, any specific items to this checklist that 
would need to be included from your organisation's perspective. 

2. Interview a fellow project manager in your class and ask them what kind of closure procedures they have previously 
used to complete a project. Also ask them to provide {a minimum of two) examples of when lessons-learned have 
been used in a project they are familiar with. 
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3. What are two lessons-learned that you have gleaned from a recent project in your organisation? Was a lessons- 
learned workshop carried out? What Action Plans were generated to improve project management processes as a 
result of the lessons-learned? 

4. In small groups, discuss how benefits are managed at project closure. Do your experiences differ from each others”? 
What recommendations would you make to improve the process in future projects and why? 


Case study 


Fred, a project manager, is currently closing out a project. The PMO is pressing him to release project staff and also 
for the final project deliverables to the business to be handed over. Fred, however, is resisting releasing some key 
members of the project team, given that the project has experienced some issues with the procurement and HR 
aspects of running the project. 

The project has succeeded in providing quality outcomes to the business up to this point, and has been praised 

for its practices in engaging with the various business stakeholders and for the ‘Agile’ approach taken towards 
communication with these stakeholders. The project sponsor has already congratulated the project team and project 
manager for having delivered some outstanding results to business operations. These results have really improved 
the effectiveness and efficiency of a key number of the business's processes and how these integrate with the 
existing IT infrastructure. 

Fred has prepared a project closure report and, pending final deliverables to the business, is getting ready for a 
mandatory presentation to the project sponsor and other key interested parties. The project closure report he has 
prepared is focused on reporting the triple constraints only and there appears to be no process in place with the 
PMO to facilitate a post-implementation review. Fred has some concerns at this point and has therefore enlisted the 
skills of you, a more experienced project manager, to provide input into proceedings. 


Your tasks 
As the more experienced project manager: 


1. Prepare a briefing document about improvements that could be made to: 
(a) the final project closure report 


(b) the process and timing of a postimplementation review. 
2. Produce a Lessons-Learned Register of both positive and negative lessons as you (personally) perceive them, using 


the hooks provided in the case study. You will have to make assumptions, or maybe you have real-world experience 
you can bring into your responses. 


3. Comment on some ofthe potential impacts that may be experienced due to the timing of releasing project team 
members in this case study (from both Fred’s and the PMO’s perspectives). 
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Learning elements 
20A Understand the role of a project manager, from a hands-on career perspective. 


20B Draw together the necessary links that make a successful project manager. 
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20.1 INTRODUCTION 


This chapter discusses building a career in project management. @®ne point to remember is that 
pursuing a career in project management does not necessarily mean you will ever have the title of 
‘project manager’. Yes, there are a growing number of fields in which project management is a career 
path, but there are many more jobs in which project management is not a title but a job requirement. 
This underscores a major advantage to being good at managing projects, and that is: the basic 
project management methodology you have been exposed to in this text is transferable across most 
businesses and professions. Think back to the Snapshots from Practice in earlier chapters. They were 
not limited to one or two industries or professions, but rather entailed a smorgasbord of industries 
and professions. So, whether you are interested in a formal career in project management or just see 
managing projects as being important for your aspirations, this chapter provides advice for further 
developing your project management skills and knowhow. 


20.2 CAREER PATHS 


There is no set career path for becoming a project manager. Career avenues vary from industry to industry, 
organisation to organisation and profession to profession. What can be said is that advancement occurs 
incrementally. You don't simply graduate and become a project manager. As in other careers, you have to 
work your way up to the position. For example, in projectbased organisations such as construction firms, 
you may begin by working on several projects as an assistant engineer, and then take an assignment as a 
project analyst. Fromthere you may be promoted to principal engineer, advance to assistant project manager, 
assume the role of project manager over a small project, and then continue to bigger, riskier projects. In 
other organisations, project management careers run parallel with functional advancement. See Snapshot. 
from Practice: Dr Neil Pearson as an example of how careers can intertwine with project management. 

@ther people find that their project management. responsibilities expand as they move up the 
organisation's hierarchy. For example, a former marketing student began her career as an assistant 
buyer for a large retail company. She then became area sales manager at a specific store and became 
involved on a parttime basis in a series of projects, acting as a facilitator of focus groups. She was 
promoted to buyer and eventually became a store manager. In her current position, she coordinates a 
variety of projects ranging from improving the sales acumen of her sales force to altering the physical 
layout of the store. Although the title of ‘project manager’ does not appear in her job description, more 
than 50 per cent of her work involves managing projects. 


SNAPSHOT FROM PRACTICE Dr Neil Pearson 





1999-2002 
2002—04 
2004-05 
2005-07 
2007—10 
2010-15 


2015-18 
2019-Current 


T Service Desk Manager (UK ane US) 
Program an@ Project Manager (US) 

Data Architecture Manager (Australia) 
Program ane Project Manager (Australia) 
Strategic Advisor (Australia) 

Corporate Educator ane Consultant 
Australia) 


| don't remember a day in my career, 
after leaving university post my first 
degree, where projects have not been 
a part of any role | have held. Certainly, 
as an IT manager, prior to taking a 
service @esk management role, we 
lived by projects. | remember sitting 





Corporate Educator ane Consultant (UK) 
Corporate Educator ane Consultant 
Australia) 
www.projectmanagementinpractice. 
world launched 

Lean Six Sigma training launched 


in the office of the CFO on a regular basis, Business 
Case in hand, seeking funding to undertake business- 
driven infrastructure projects. Project manager and 
operational manager often do go hand-in-hand. As the 
service desk manager, | was faced with some of my most 
complex projects, as you can imagine; in consolidating 





services globally into a follow-the-sun, 24/7, multilingual 
environment, the management of stakeholders and 
communications consume@ 80 per cent of my day 
{this was aside from my day job of actually running the 
operations of the Europe, Middle East and Africa (EMEA) 
service desk on a daily basis); this role took me to the 
United States. 

On moving away from the service desk environment 
| was challenged by a large backoffice consolidation 
project for a customer-facing ticketing system at Oracle 
Corporation. In what was, again, a global project, | spent 
many hours on teleconferences (often to the early hours 
of the morning), holding project team meetings, calling 
subject matter experts (SMEs) or participating in a raft 
of technical meetings. The project was a success, | am 
glad to say. | then went on to program manage a large 
portfolio while being project manager to a number of 
smaller business improvement projects. The portfolio 
management slant to the role brought with it a whole set 
of new challenges. 

On moving to Australia, the bulk of my time was 
spent at a government-owned utility where | worked 
within the project management office (PMO) attending 
to various aspects of the PMO, including developing and 
embedding a project management framework—base@ on 
the Project Management Institute’s Guide to the Project 
Management Body of Knowledge (PMBOK)—across the 
business. This was a great role, working in a team of 
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like-minded people. It was here that | starteel my PhD in 
a business and ICT research program; running my PhD 
like a project really challenged my supervisors—but this 
paid off As soon as | successfully completed my PhD, | 
decided (being a practical person) academia was not 
the full-time future, and so | moved into the corporate 
education market and set up my own business. | am now 
able to leverage my academic background ane bring 
practical hands-on training across project and program 
management, strategy (being a Blue Ocean Strategy 
practitioner) and Lean Six Sigma to organisations within 
the public and corporate sectors. Project management 
has provided me with opportunities not envisaged 
when leaving university way back in 1990. | encourage 
students to grasp opportunities ane not to be daunted 
by seemingly insolvable challenges; by using your 
project management skills, Knowledge and the tools and 
techniques, just about all projects are solvable. 

Dr Neil Pearson has recently expanded his project 
management courses to include the popular Lean Six 
Sigma approach to managing continuous improvement 
projects, offering Lean Six Sigma, Yellow belt, Green 
belt, Black belt, and Sponsor courses to complement 
the BSB Certificate IV, Diploma and Advanced Diploma 
courses in program ane project management. Please 
feel free to contact Dr Neil (info@drneilpearson.com) 
with your Lean Six Sigma and Project Management 
training needs. 


20.2.1 Temporary assignments 


@ne aspect of project management that is unique is the temporary nature of assignments. With line 
appointments, promotions are, for the most part, permanent and there is a natural, hierarchical 
progression to positions with greater authority and responsibility. In the example of the former 
marketing student, she progressed from assistant buyer to sales manager to buyer to store manager. 
@nly under very unusual circumstances would she regress to being a buyer. Conversely, tenure is 
rarely granted to project managers. @nce the project is completed, the manager may return to their 
previous department, even to a lesser position; or, depending on the projects available, they may be 
assigned to manage a more or less significant project. Future work depends on what projects are 
available at the time the individual is available and how well the last project went. A promising career 
can be derailed by one unsuccessful project. 


20.2.2 Pursuing a career 


If you are considering a career in project management, you should first find out what specific project 
job opportunities exist in your company. Talk to people in project management positions and find out 
how they got to where they are and what advice they can give you. Because career paths, as noted 
earlier, vary from organisation to organisation, you need to be attuned to the unique pathways within 
your company. For example, retail companies naturally assign marketing managers to projects. 
Electronics firms, on the other hand, typically assign engineers to be project leads. 
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Table 20.1 Project management careers/roles 


Construction and civil engineering. Infrastructure projects 
(bridges/tunnels/water treatment/electrical industry) for 
office buildings and housing developments. 
Military-related projects offered by the large contractors 
to governments and military. Here, highly structured and 
mature project environments often exist. Projects are 
often complex and have long gestation periods. 


Government roles from health to community. 
Governments often have generous support and 
training programs and offer starting project managers a 
stepping-stone. 


Health and health care services, including aged care. 


Mining and exploration. Offering great opportunities 
to travel and broaden your international project 
management experience. 


ICT permanent and contract project management 
engagements. Ranging from business and ICT projects 

in the areas of business process management, system 
enhancements to server replacement and desktop rollout 
projects. 

Notfor-profits often offer socially rewarding projects; 
remuneration is often at the lower end but the social 
good you will be doing more than makes up for this. 
Again, opportunities for international travel abound. 
Education, universities and private education providers. 


Moving content to online environments including 
Learning Management System (LMS), Content 
Management System (CMS) and Artificial Intelligence (Al)- 
based learning systems. 


@nce you have concluded that you wish to pursue a career in project management, or see 
project management as an avenue for advancement, you need to share your aspirations with your 
immediate superior. Your superior can champion your ambitions, sanction additional training in 
project management and assign immediate work that will contribute to your project skill base. Some 
careers/roles where project management skills are always in demand or required are indicated in 
Table 20.1. 


20.5 PROFESSIONAL TRAINING, CERTIFICATIONS 
AND QUALIFICATIONS 


Historically, most project managers never received formal training in project management. They 
mastered the job through on-thejob training, buttressed by occasional workshops on specific project 
topics such as project scheduling or negotiating contracts. It wasn’t until recently that universities 
started offering courses on project management. outside of schools of engineering. Regardless of 
your level of training, you will likely need to supplement your education. Many large companies have 
inhouse training programs on project management. For example, at one time, Hewlett-Packard had 
more than 32 training modules in its project management curriculum, which is organised around 
five levels of experience: project team, new project manager, project manager, experienced project 
manager and manager of project managers. Take advantage of professional workshops, which can 
cover a range of specific project management tools and topics. Continued education should not be 
restricted to project management. Many technical professionals return to universities to complete an 
MBA or take night classes in management to expand their general business background. 

Many professionals find it beneficial to jointhe Project Management Institute (PMI). Membership 
entitles you to subscriptions to PMI publications including the academic Preject Management Jeurnal 
and the PM Netwerk, a trade magazine. PMI sponsors workshops and national forums on project 
management. When you join PMI you can also become a member of your local chapter. These chapters 
meet. on a monthly basis and provide project professionals with opportunities to network and learn 
from each other. 

In addition, PMI, as part of its effort to advance the profession, certifies mastery of project 
manager competencies through a formal examination that covers the entire body of knowledge 
of project management. Two of the most popular certifications are Certified Associate in Project 
Management (CAPM) and Project Management Professional (PMP). The CAPM is designed for young 
professionals getting started in the field while PMP is restricted to seasoned veterans with significant. 
project management experience (see Table 20.2). 


Table 20.2 PMI certification requirements 


CAPM 


Certified Associate in Project 
Management 


Contributes to project team 
Secondary degree (high school 
diploma, associate’s degree or the 
global equivalent) 

1500 hours of project experience 
OR 

23 hours of project management 
education completed by the time you 


Full name 


Project role 
Eligibility requirements 
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PMP 
Project Management Professional 


Leads and directs project teams 

Secondary degree (high school diploma, 
associate’s degree or the global equivalent) 
7500 hours leading and directing projects 
35 hours of project management education 
OR 

Four-year degree 

4500 hours leading and directing projects 


sit for the exam 35 hours of project management education 


Exam information 3 hours; 150 multiple-choice 
questions 


Retake the exam every five years 


4 hours; 200 multiple-choice questions 


To maintain the certification 3-year cycles 


60 professional development units (PDUs) 
per cycle, spread across the PMI Talent 
Triangle” 


Most students, by taking a formal class in project management at university level, qualify to sit for 
the CAPM exam. Both the CAPM and PMP exams are based on the official PMB@K published by PMI. 
There are several ‘prep’ books available to assist students in preparing for the examinations and these 
can provide useful tips as well as some practice exam samples. 

Passing a project management exam and being awarded a CAPM or PMP credential clearly 
signposts your competence in the field. Snapshot from Practice: Ginger Butler provides an example of 
how one former student used the CAPM to launch their career in project management. 

In Australia, you can pursue qualifications in the vocational sector—such as a Certificate IV, 
Diploma or Advanced Diploma in Project Management—and, as indicated in Chapter 1, there are a 
number of professional bodies that offer certifications. Remember, ‘qualifications’ stay with you for 
life whereas ‘certifications’ rely on currency, and if not maintained, will be lost. Maintenance requires 
that you must be practising in the project management arena at an appropriate level. 

Table 1.5 in Chapter 1 provides a comparison of project management vocational qualifications 
and some of the ‘equivalent’ certifications available from professional bodies both within and outside 
of Australia. However, deciding which particular certification type to pursue should not be taken 
lightly as it can take a considerable amount of time (and money) to undertake. 

Do not underestimate the importance of supplementing a solid professional career with formal 
qualifications and certifications. Recruiters and organisations alike will often include selection criteria 
in position descriptions mandating a certain level of qualification and certification, without. which, as 
a candidate, you may find yourself placed in a pile of candidates who do not meet the requirements 
for interview. 

Beyond the vocational qualifications, the higher education sector offers many undergraduate degrees, 
master degrees and even a PhD, contributing a unique area to the project management discipline. You 
will most. probably find that project management is an elective unit of study for most. degrees these 
days—indicating the growing takeup of project management methodologies in industry, not-for-profits 
and government alike. 


20.4 GAINING VISIBILITY 


As you accumulate knowledge and techniques, you need to apply them to your immediate job situation. 
Most people's jobs entail some form of project work, whether realising a mandated objective or simply 
figuring out ways to improve the quality of performance. Gantt charts, responsibility matrixes, critical 
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path method (CPM) networks and other project management tools can be used to plan and implement 
these endeavours. It may also be wise to look outside the workplace for opportunities to develop project. 
management skills. Active involvement in your local community can provide numerous opportunities 
to manage projects. ®rganising a local soccer tournament, managing a charitable fundraising event or 
coordinating the renovation of the neighbourhood park can allow you to practise project management. 
Furthermore, given the volunteer nature of most of these projects, they can provide you with an 
excellent training ground to sharpen your ability to exercise influence without formal authority. 
Regardless of how competent and worthy you are, your project management skills must be visible to 
others for them to be recognised. Many project managers’ careers began by volunteering for task forces 
and small projects. Ideally, you should select task forces and projects that allow you access to higher-ups 
and other departments within your organisation, providing you with opportunities to develop contacts. 
This was certainly true for a former student named Bob, who escaped the trenches of a large 
corporation by volunteering to lead the organisation’s annual United Way campaign. While an important 
cause, directing the United Way campaign was generally given to someone who was expendable. 
This was true for Bob, whose career had bottomed out. Bob took advantage of the United Way task 
force to show off his project management skills. Through recruiting key participants, establishing 
a shared vision, managing milestones and contagious enthusiasm, the campaign was a resounding 
success, shattering previous records. Bob's efforts caught the attention of top management and he 


was rewarded with more project work. 


SNAPSHOT FROM PRACTICE Ginger Butler 





2000 BS Business Administration 

2000-07 Software Analyst 

2007 Master Business Administration (MBA) CAPM 
PMI Project Management Certification 

2007 Project Manager 

2008 Director Project Management Office 

2009 Vice President, Products and Operations 


After 10 years of bookkeeping, | decided to return to college 
to complete a bachelor’s degree in business administration— 
management information systems. It was in my junior year 
that | took a project management course. | was impressed 
with how project management methods can break down the 
most complicated projects into steps that can then be turned 
into processes that will likely result in successful projects. 
The next seven years were spent as a software analyst. Time 
and time again, | could see the need for effective project 
management in our software development shop. Slowly, | 
started to apply what | had learned and began to realise how 
useful project management tools and techniques were to 
getting things done. 

| knew that | needed to learn more. | was contemplating 
whether to take a project management course to acquire 
project management certification or make a bolder move 
and earn an MBA. | made the decision to earn an MBA and, 
once again, had the opportunity to take an advanced course 
in project management. Before | graduated, | orchestrated a 
project management certification prep course in which | and 
11 other graduate students ultimately earned our certification. 


One week after graduation, | took a project 
management position at Avant Assessment. Project 
management certification was a requirement for the job. 
Avant Assessment (founded in 2001) designs, develops 
and delivers four-skill language proficiency assessments 
that are standards-based, validated and delivered in a 
Web environment. The company embraced the science 
of project management and provided an amazing 
opportunity for me to make a significant impact as a project 
manager. Within two years, | was promoted to director of 
Our project management office. From there | was able to 
create cohesive and effective processes in our production 
department and have repeated the process development 
successes in our products department. 

Recently, | was promoted to director of operations. This 
is a direct result of what | have been able to accomplish 
with education and continued learning about project 
management. By coupling the MBAwith project management, 
| was prepared to take on significant challenges and 
produce tactical, operational and strategic improvements 
within and across departments. Granted, | was in the right 
place at the right time to get such a great opportunity at 
Avant Assessment. This company is an innovative thinking, 
action-oriented company that has been very rewarding to 
work for. Avant recognises and encourages personal and 
professional growth and development. Thanks to the spark 
of interest found years ago in project management, and to 
Avant Assessment for igniting a passion for improvement, 
my career has skyrocketed. 
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Mentors 


In pursuing your ambition, you should continually be on the lookout for a mentor. Most fast-track 
managers acknowledge that mentors played a significant role in their advancement. Mentors are 
typically superiors who take a special interest in you and your career. They use their clout to champion 
your ambitions and act as a personal coach, teaching you ‘the ropes to skip and the ropes to know’. 
This special treatment does not come without a price. Mentors typically require fervent loyalty and 
superior performance; after all, the mentor's reputation rests on your performance. How do you finda 
mentor? Most people say it just happens. But it doesn’t happen to everyone. Mentors typically seek A+ 
workers, not C workers, and you must make your abilities known to others. 

Many organisations, and some professional bodies (e.g. PMI has a mentoring scheme available in 
Australia), have instituted formal mentoring programs in which experienced project managers are 
assigned to promising young managers. Although the relationship may not evolve to the personal 
level experienced with an informal mentor, designated mentors play a very similar role in coaching 
and championing one’s professional progress. You should take advantage of this opportunity to learn 
as much as you can from these seasoned veterans. Some organisations will also use the services 
of external consultants to mentor people internally within the organisation. The authors have been 
involved in many coaching and mentor engagements and have been rewarded by seeing project 
managers take on increasingly complex projects. 

Since much project work is temporary and contractual in nature, it is important to develop 
professional contacts that may lead to future work. Attending conferences, trade fairs and workshops 
provides good opportunities to ‘network’ and develop social connections that might precipitate project 
assignments. These social/professional networks can provide a safety net for project work during 
times of downsizing and layoffs. 


Networking 


Attending networking events can be a very beneficial experience for project managers. These types 
of events can be used to: 


gain further project management formal knowledge 
meet and mix with like-minded people 


learn about new project management best practices 


learn from other people's success stories taking place in your locale. 


Networking events may be organised by professional membership organisations, such as the 
Australian Institute of Management (www.aim.com.au) or project management-specific organisations, 
such as the Australian Institute of Project Management (AIPM) (www.aipm.com.au) and local 
chapters of PMI (www.pmi.org/Get-Involved/Chapters-PMI-Chapters.aspx). The latter two institutes 
regularly hold a wide range of networking and professional development events, providing interesting 
networking opportunities for building your own networking base. 

@nline networking is also another popular medium. Again, there are numerous forums, blogs, 
wikis and websites offering online communities for project managers to learn from and contribute to. 
Some useful sites include: 


www.projectmanagement.com (formally known as Gantthead.com) 
www.pmhut.com 


www.projecttimes.com 


pmtips.net 
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E https://www.projectmanager.com 
Em pmstudent.com 


E betterprojects.net 


There are many more out there, but they are too numerous to list here. The reader is encouraged to 
‘Google’ and seek out other online communities that may have more specific industry/sector relevance 
as well. @ther networking opportunities exist through professional networking services such as 
LinkedIn (www.linkedin.com), where many project management and industry groups exist. Platforms 
such as LinkedIn also provide an ideal place to grow your networks and develop your online presence. 


20.5 SUCCESS IN PROJECTS 


Ultimately your goal is to accumulate a portfolio of project management experiences that broaden 
your skill base and reputation. Early on you should choose, when possible, projects with the greatest 
learning opportunities. Pick projects more for the quality of the people working on them than for the 
scope of the projects. There is no better way to learn how to be an effective project manager than by 
watching one at work. Keep a diary of your observations and review and refine lessons learned. Later, 
as your confidence and competency grow, you should try to get involved in projects that will enhance 
your reputation within the firm. Remember the comments about customer satisfaction. You want. to 
exceed your superior’s expectations. Avoid run-of-the-mill projects or assignments. Seek highprofile 
projects that have some risks and tangible payoffs. At the same time, be careful to be involved in 
projects commensurate with your abilities. 

Finally, despite your efforts, you may find that you are not making satisfactory progress towards 
your career goals. If this is your appraisal, you may wish to seriously consider moving to a different 
company or even a different industry that might provide more project management opportunities. 
Hopefully, you have managed to accumulate sufficient project management experience to aid in your 
job search. ®ne advantage of project work over general management is that. it is typically easier to 
highlight and ‘sell’ your accomplishments. 


ummary 


It is rare to find a job or a career path where one would not benefit from being good at managing projects. Students 
starting their careers should take advantage of every opportunity to continue to develop and expand their project 
management skills. They should volunteer to work on task forces, take advantage of training opportunities and 
apply project management tools and techniques to their work. They should signal to their superiors their interest 
in project management and garner project assignments. Over time, they should accumulate a portfolio of project 
management experiences that establishes their skill base and reputation as someone who gets things done quickly 
and done right. 

As you pursue your career we offer two suggestions for you as a project manager: 


4. Maintain a sense of the big picture: Engage regularly in what some have called ‘helicopter management, which 
means expand your perspective beyond immediate concerns and assess how the project fits into the larger scheme 
of things. Project managers need to constantly assess how the project supports the mission, vision and strategy 
ofthe firm, how the project is affecting the rest of the organisation, whether the expectations of stakeholders 
(customers) are changing and what key project interfaces have to be managed. 

2. Remember that successful project management is essentially a balancing act: Project managers need to balance 
the soft (people) side of project management with the hard (technical) side, the demands of top management with the 
needs of team members, and short-term gain with long-term need. 

The authors wish students every success in achieving their vocational qualifications and building their careers in 
the project management profession. 
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https://www.pmi.org/certifications/types/certified-associate-capm 
https://www.pmi.org/certifications/types/pro ject-management-pmp 
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https://apmg-international.com 
www.projectmanagementinpractice.world 
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Review questions 


4. Why are project management knowledge and skills transferable across industries and professions? 
2. Is there a set career path in project management? Explain. 
3. How can a mentor help someone pursue a career in project management? 


= 


Interview someone who has worked as a project manager or project management professional. Find out: 
(a) How did they get started in the field? 

(b) How has their career progressed? 

(c) What advice would they give someone wishing to pursue a career in project management? 


N 


Interview someone who works in a field you are interested in pursuing 

(a) How did they get started in the field? 

(b) How important is project management in the field? In their current job? 

(c) What advice would they give someone wishing to pursue a career in their field? 


w 


Use an internet job search engine (e.g. www.seek.com.au) and search for jobs in the field of project management. What 
did this search reveal about: 





(a) the demand for project managers? 
(b) the importance of certification? 
(c) the different industries looking for project managers? 


Epilogue 





With Chapter 19 Project closure, the project life cycle is complete. You have been exposed to the core elements of 
projectmanagement. We have consciously tried to incorporate a blend of sociocultural and process practices required 
to successfully manage any project. These best practices are transferable across any sector, any industry and any 
organisation. Your understanding of these chapters should enhance your ability to make a positive contribution in 
any project environment and by pursuing a Certificate IV in Project Management Practice or Diploma of Project 
Management, your career will be enhanced by demonstrating your project knowledge and experience. 

The supplemental chapter online expands on the core chapters by covering project management career paths. 
You may find it useful as you consider your future. Chapter 20 also presents a useful summary table mapping the 
parallels between the different levels of qualification and the vast array of certification types available through 
various professional bodies. 

The authors encourage the reader to continue project management in their chosen field, whether this be 
environmental sustainability, technology, construction, mining, government or notfor-profit. Remember, yeu 
are the one in charge of your career and where you take it. 
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Glossary 





360-degree feedback A multi-rater appraisal system 
based on performance information that is gathered 
from multiple sources (superiors, peers, subordinates, 
customers). 


5 Whys A method in which a series of five ‘why’ 
questions are asked to deepen understanding of the risk, 
or the root cause of a problem. 


A 


activity Task(s) of the project that consumes time while 
people/equipment either work or wait. 


activity duration Estimate of time (hours, days, weeks, 
months, etc.) necessary to complete a project task. 


Actual Cost of the Work Completed (AC) The sum of 
the cost incurred in accomplishing work. Previously 
this was called the actual cost of the work performed 
(ACWP). 


Actual Cost of the Work Performed (ACWP) Actual cost 
of the work performed in a given time period. The sum of 
the costs incurred in accomplishing work. 


Agile Project Management (Agile PM) A family 
of incremental, iterative development methods for 
completing projects. 


ALARP (As Low As Reasonably Possible) A term often 
applied to the management of risk in an organisation. 


Analytic Hierarchy Process(AHP) A method used to 
prioritise projects or investments, often implemented 
within Project. Portfolio Management (PPM) software. 


Activity-on-Arrow (AOA) Method for drawing project 
networks. The activity is shown as an arrow. 


Activity-on-Node (AON) Method for drawing project 
networks. The activity is on the node (rectangle). 


apportionment method Costs allocated to a specific 
segment of a project by using a percentage of planned 
total cost—for example, framing a house might use 25 
per cent of the total cost, or coding a teaching module 40 
per cent of total cost. 


AS/NZS/ISO 31000:2009 The risk management 
standard describing the principles, framework and 
process for the management of risk. The standard is 
often applied to the management of risk in a project 
environment. 


assumptions A statement of truth, assumed to be true 
within the project.environment, for example, availability 
of ‘testers’ during software testing. Assumptions should 
be reviewed froma risk perspective. 


Australian Institute of Project Management (AIPM) The 
premier project management organisation in Australia. 


Australian Skills Quality Authority (ASQA) The national 
regulator for Australia’s vocational education and 
training sector. 


avoiding risk Elimination of the risk cause before the 
project begins. 


backward pass The method used to compute the late 
start and finish times for each activity in the project. 
network. 


balanced matrix A matrix structure in which the 
project manager and functional managers share roughly 
equal authority over the project. The project manager 
decides what needs to be done; functional managers are 
concerned with how it will be accomplished. 


baseline A concrete document and commitment; it 
represents the first. real plan with cost, schedule, and 
resource allocation. The planned cost and schedule 
performance are used to measure actual cost and 
schedule performance. Serves as an anchor point for 
measuring performance. 


BATNA (Best Alternative To a Negotiated 
Agreement) A strong or weak BATNA indicates your 
power to negotiate with the other party. 


benchmarking A technique of establishing a baseline 
measure from which to compare future performance. 
Can be carried out at a project level or on the project's 
product/service. 


Benefit Cost atio (BCR) A ratio of costs associated 
with carrying out the project, to benefits received from 
delivery of the project. 


bottom-up estimates Betailed estimates of work 
packages usually made by those who are most familiar 
with the task (also called micro estimates). 


brainstorming Generating as many ideas/solutions as 
possible without critical judgment. 


Budget at Completion (BAC) Budgeted cost at 
completion. The total budgeted cost of the baseline or 
project cost. accounts. 


budgetreserve Reserve setup to cover identified risks 
that may occur and influence baseline tasks or costs. 
These reserves are typically controlled by the project 
manager and the project. team. See management reserve. 


Budgeted Cost of the Work Performed (BCWP) The 
value for completed work measured in terms of the 
planned budget for the work. The earned value or 
original budgeted cost. for work actually completed. 


Business Process Model and Notation(BPMN) A 
process notation designed to model business processes 
within an organisation. 


Build-Own-Operate-Transfer (BOOT) A risk 
management provision in which the prime contractor not. 
only builds the facility, but also takes over ownership 
until its operation capacity has been proven before final 
transfer of ownership to the client. 


burst activity An activity that has more than one 


activity immediately following it. 


c 


change control 
accepting or rejecting change, and documenting any 


The process of documenting, reviewing, 


change to the project baseline. 


Change Management System A defined process for 
authorising and documenting changes in the scope of a 
project. 


chart of accounts A hierarchical numbering system 
used to identify tasks, deliverables, and organisational 
responsibility in the work breakdown structure. 


checksheet An often used tool used at various points 
in the project. management life cycle to check that 
procedures, activities and tasks have been completed 
against a specified list of questions. 


closed tender Tendering to a closed (list) of suppliers. 


See also open tender. 


co-location A situation in which project members 
including those from different organisations work 
together in the same location. 


committee charter A charter that describes the purpose, 
objectives and decision making accountabilities of a 
committee, for example, the project. steering committee. 


communication plan A plan that defines information 
to be collected and distributed to stakeholders based on 
their requirements. 


GLOSSARY 


Communications Management Plan @ne of several 
management plans that define the governance, roles, 
procedures and other static predetermined procedures 
that are to be followed within the project environment. 


Communications Matrix A matrix of communications 
(and all the attributes of a communication), that 

are planned to be sent to a stakeholder/group of 
stakeholders. 


Communications Register A register of all formal, 
outgoing project communications. Useful to refer to 
in the event of questions being raised against past 
communications. Provides an audit trail of sent 
communications. 


concurrent engineering or simultaneous 

engineering Cross-functional teamwork in new- 
product development projects that provides product 
design, quality engineering, and manufacturing process 
engineering all at the same time. 


Configuration Management (CI The concept that all 
artefacts in a project environment should be controlled 
in a known manner. Artefacts may include project. 
management documents and also the many hundreds 
of artefacts that related to the product or service being 


produced by the project. 


consensus decision making Reaching a decision that 
all involved parties basically agree with and support. 


constraints Statements which describe elements that 
will constrain the project. For example, if a resource 
type is constrained, the project. manager would review 


constraints in scoping and decide if any risks result. 


contingency A percentage of the total project budget 
held by the project steering committee/sponsor. Access 
to contingency funds is achieved through the project. 
change/variation process. 


contingency fund See contingency reserve. 


contingency plan A plan that covers possible identified 
project risks that may materialise over the life of the 
project. 


contingency reserve Usually an amount of money or 
time set aside to cover identified and unforeseen project. 
risks. 


contract A formal agreement. between two parties 
wherein one party (the contractor) obligates itself 

to perform a service and the other party (the client) 
obligates itself to do something in return, usually in the 
form of a payment to the contractor. 


contract types See contract 


GLOSSARY 


contractor and supplier evaluation The activities 
surrounding the selection of the suppliers of products and 
services to be procured into the project. 


contribution/commitment grid A stakeholder analysis 
tool aimed at ascertaining where stakeholders sit in 
relation to contribution/commitment and where the 
project manager/project team would like to see the 
stakeholder move. 


control charts A method of reporting on usually the 
Quality of the projects outcomes and outputs. Usually 
generated as apart of Quality Control (QC) activities. 


cost account A control point of one or more work 
packages used to plan, schedule, and control the project. 
The sum of all the project cost accounts represents the 
total cost of the project. 


cost baseline The approved project. budget as a result. 
of the Planning phase of the project life cycle. This is the 
baseline from which Change (variation) Management 
would be applied to in order to control costs. 


Cost of Quality (CoQ) The cost of not achieving 

quality in the project environment against the cost. of 
implementing quality in the project environment. There 
are costs associated with carrying out quality (additional 
activities) as well as not carrying out quality (additional 
rework). 


Cost Performance Index (CPI) The ratio of work 
performed to actual costs (EV/AC). 


cost-benefit analysi See Benefit Cost Ratio (BCR) 


cost-plus contract A contract in which the contractor 
is reimbursed for all direct allowable costs (materials, 
labour, travel) plus an additional fee to cover overhead 
and profit. 


cost variance (CV) The difference between EV and AC 
(CV = EV — AC). Tells if the work accomplished cost 
more or less than was planned at any point over the life 
of the project. 


crashing Shortening an activity or project. 


critical path The longest activity path(s) through 
the network. The critical path can be distinguished by 
identifying the collection of activities that all have the 
same minimum slack. 


Critical Path Method (CPM) A scheduling method based 
on the estimates of time required to complete activities 
on the critical path. The method computes early, late, and 
slack times for each activity in the network. It establishes 
a planned project. duration, if one is not imposed on the 
project. 


culture The totality of socially transmitted behaviour 
patterns, beliefs, institutions, and all other products of 
human work and thought characteristic of a community 
or country. 


culture shock A natural psychological disorientation 
that most people suffer when they move to a culture 
different from their own. 


currencies A set of commonly traded organisational 
currencies often applied in working with stakeholders 
internal and external to the organisation. 


D 


daily Scrum meeting A short status meeting held 
daily by each team during which the team members 
synchronise their work and progress as well as report 
any impediments for removal by the Scrum master. 


dangler An activity in a project schedule that has no 
relationship to any successor activities . 


decision tree/decision tree analysis A method to assist 
in the selection of decisions or in the probability of risk 
alternatives. 


dedicated projectteam An organisational structure in 
which all of the resources needed to accomplish a project. 
are assigned full time to the project. 


deliverable A major product or result that must be 
finished to complete the project. 


deliverable acceptance A formal documented process 
for the sign-off of deliverables. 


Delphi Technique or Delphi Method A group method to 
impartially collect perspectives and input into a problem 
or situation. 


direct costs Costs that are clearly charged to a specific 
work package—asually labour, materials, or equipment. 


dummy activity An activity that does not consume time; 
it is represented on the A@A network as a dashed line. A 
dummy activity is used to ensure a unique identification 
number for parallel activities and used to maintain 
dependencies among activities on the project network. 


duration (DUR) The time needed to complete an 
activity, a path, or a project. 


dysfunctional conflic Disagreement that does not. 
improve project performance. 
E 


early finish (EF The earliest an activity can finish if all 
its preceding activities are finished by their early finish 
times (EF = ES + BUR). 


early start (ES) The earliest an activity canstart. Itis 
the largest early finish of all its immediate predecessors 
(ES = EF — BUR). 


earned value (EV) The physical work accomplished 
plus the authorised budget for this work. Previously this 
was called the budgeted cost of work performed (BCWP). 


Earned Value Management (EVM) or Earned 

Value Analysis A technique for measuring project 
performance and progress, based on a quantitative 
assessment of project.progress and ‘value’ delivered. 


Elevator Pitch (EP) A short snappy pitch which can be 
used in the communication of the project or elements of 
the project. 


emotional intelligence (EQ) The ability or skill to 
perceive, assess, and manage the emotions of one’s self 
and others. 


Enterprise Resource Planning (ERP) system Corporate 
IT systems that provide a repository of data on company 
information from project-related and financial, to 
resource information. 


escalation A control mechanism for resolving problems 
in which people at the lowest appropriate level attempt to 
resolve a problem within a set time limit or the problem is 
‘escalated’ to the next level of management. 


Estimated Cost at Completion (EAC) The sum of actual 
costs to date plus revised estimated costs for the work 
remaining in the WBS. 


Estimating tools See ETC 


ETC, Estimated cost to complete (uses formula to 
compute estimates). 


ETC,. Estimated cost to complete (uses expert 
estimates). 


event A point in time when an activity(s) is started or 
completed. It does not consume time. 


exception report A type of project status report that 
reports on the status of a project based on exceptions 
(deviations) from what was planned to take place (as 
documented in the baseline project management plan). 


F 


Failure Mode and Effects Analysis (FMEA Each 
potential risk is assessed in terms of severity of impact, 
probability of the event occurring, and ease of detection. 


fast tracking Accelerating project completion, typically 
by rearranging the network schedule and using start- 
to-start. lags (i.e. planning tasks to occur in parallel as 
opposed to in sequence). 
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feature A piece of a product that delivers some useful 
functionality to a customer. 


finance/ERP ystem See Enterprise Resource Planning. 


finish-to-finish (FF) relationsh Where the finish of one 


activity depends on the finish of another activity. 


finish-to-start (FS) relationshi The finish-to-start 
relationship represents the typical relationship 
between two activities, where the start. of the successor 
relationship is dependent on the predecessor being fully 


completed. 


fishbone (cause-effect) diagr A root. cause analysis 
technique that assist the project team and project 
manager in working out what the root cause/s to a 
problem could be. 


fi ed-price or “lump sum” contract A contract in which 
the contractor agrees to perform all the work specified in 
the contract at a predetermined, fixed price. 


floa See slack. 


Forecasted Estimated Cost to Complete (ETC ;) 
Estimated total cost of a project based on CPI. 


forward pass The method for determining the early 
start and finish times for each activity in the project 
network. 


free slack The maximum amount of time an 
activity can be delayed from its early start (ES) 
without affecting the early start (ES) of any activity 
immediately following it. 


full reporting A type of report that reports on all 
aspects of the projects progress. Usually includes aspects 
of; scope, time, quality, cost, human resources, risk, 
procurement, communications and stakeholders, 


function points Points derived from past software 
development pro jects that assist in the development. 
of estimating the amount of time to construct a new 
software project. Also referred to as a functional point 
analysis. 


functional conflic Within the context of project 
behaviour occurs when low to moderate levels of conflict 


improve the effectiveness of the team. 


functional manager A manager responsible for 
activities in a specialised department or function (e.g., 
engineering, marketing, finance). 


functional organisation functional structure A 
hierarchical organisational structure in which 
departments represent individual disciplines such as 
engineering, marketing, purchasing. 


GLOSSARY 


G 


Ganttchart A graphic presentation of project activities 
depicted as a time-scaled bar chart. 


gates (or kill points) A review point in the project life 
cycle where decisions are made on the viability of a 
project, or to seek approvals on a project progress into 
the next phase or stage. 


General and Administrative (G&A) (or indirect) costs 
Indirect costs which should not be overlooked by the 
project manager, these could include items such as 
telephones, management time and PM® administration. 


going native Adopting the customs, values, and 
prerogatives of a foreign culture. 


Golden Rule Bo unto others as you would wish them to 
do unto you. 


groupthink A tendency of members in highly cohesive 
groups to lose their critical evaluative capabilities. 


H 

hammock activity A special-purpose, aggregate activity 
that identifies the use of fixed resources or costs over 

a segment of the project—e.g., a consultant. Berives its 
duration from the time span between other activities. 


heuristic A rule of thumb used to make decisions. 
Frequently found in scheduling projects. For example, 
schedule critical activities first, then schedule activities 
with the shortest duration. 


hierarchical decomposition A method of breaking 
down a project (based on deliverables, for example), into 
successive levels of detail until the project manager has 
a level of comfort that the work can be estimated and 
scheduled accordingly. 


implementation gap The lack of consensus between the 
goals set by top management and those independently set 
by lower levels of management. This lack of consensus 
leads to confusion and poor allocation of organisation 
resources. 


Incremental, Iterative Development (IID) A cyclical 
development process in which a pro ject gradually 
evolves over time. 


innovation process The organisation's process for 
capturing innovative ideas. The project manager should 
be able to make links to this process as a part of the 
continuous improvement process. 


in-process project audit Project audits early in projects 
that. allow for corrective changes if they are needed on 
the audited pro ject or others in progress. 


insensitive network A network in which the critical 
path is likely to remain stable during the life of the 
project. 


inspiration-related currencies Influence based on 
inspiration (opportunity to do good, be the best, etc.). 


integration of quality The concept that Quality is 
integrated into all aspects of project management and in 
the delivery of the define outputs and outcomes of the 
product and services being ‘built’ by the project. 


investment business case A business case based 
around an area of investment that an organisation may 
make. The business case will include such items as a 
BCR, IRR or NPV for a number of options. 


ISO 9000 A set of standards governing the 
requirements for documentation of a quality program. 


ISO 21500:2012 IS@’s recent publication providing a 
standard around the management of projects. 


Issue Typically associated with the occurrence of a 
risk, i.e. a risk that has eventuated. 


J 


joint evaluation A process in which different parties 
involved in a project evaluate how well they work 
together. 


K 


knowledge management The theory of capturing 
knowledge (held by individuals) into a more tangible 
medium such as policies, procedures and processes for 
the benefit of the wider organisation. 


L 


laddering Under the standard finish-to-start 
relationship, when an activity has a long duration and 
will delay the start of an activity immediately following it, 
the activity can be broken into segments and the network 
drawn using a laddering approach so the following 
activity can begin sooner and not. delay the work. 


lags The amount of time between the end of one 
activity and the start of another. A duration assigned to 
the activity dependency. The minimum amount of time a 
dependent activity must be delayed to begin or end. 


lag relationship The relationship between the start and/ 
or finish of a project.activity and the start.and/or finish 
of another activity. The most common lag relationships 
are (1) finish-to-start, (2) finish-to-finish, (3) start-to-start, 
and (4) start-to-finish. 

large capital items Items which require a significant 


capital investment to be made by the project. Typically 
identified and subsequently approved early on in the 


project life cycle by authorities other than the project 
manager. 


late finish (LF The latest an activity can finish and not 
delay a following activity (LF = LS + BUR). 


late start (LS) The latest an activity can start and not. 
delay a following activity. It is the largest late finish (LF) 
of all activities immediately preceding it (LS = LF — DUR). 


law of reciprocity People are obligated to grant a favour 
comparable to the one they received. 


Lead-time Lead-time is overlap between activities that 
have a dependency. 


leading by example Exhibiting the behaviours you 
want to see in others. 


LEAN A quality philosophy based on reduction of waste 
in processes and supplier/value chains. 


learning curve A mathematical curve used to predict 
a pattern of time reduction as a task is performed over 
and over. 


lessons learned The principle of informing the current 
dynamics of the project based on events (lessons learned) 
of previous projects. Lessons learned also includes the 
capturing of lessons on the current project to not only 
continuously improve the current project but also inform 
any projects (of a similar nature) that follow. See also 
retrospectives. 


levelling Techniques used to examine a project for an 
unbalanced use of resources, and for resolving resource 
over-allocations. 


life cycle The term applied to the phases a project will 
typically go through. Under PMBoK these phases include; 
Initiation, Planning, Execution and Closure. Monitor and 
Control cuts across the whole project. 


lines of communication The concept that the number 
of lines of communication are exponential in relation to 
the number of parties being involved in a communication 
exchange. 


long lead-time items 
to procure, for example, a tunnel-boring machine with an 


Project items that take a long-time 


18-month lead time. 


Make or buy (decision) The decision made usually early 
on in the project life cycle where by the certain ‘parts’ 

of the project are either to be built within the project, or 
bought into the project. 


Management by Wandering Around (MBWA) A 
management style in which managers spend the majority of 
their time outside their offices interacting with key people. 
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management reserve A percentage of the total project 
budget reserved for contingencies. The fund exists to 
cover unforeseen, new problems—not. unnecessary 
overruns. The reserve is designed to reduce the risk 

of project. delays. Management reserves are typically 
controlled by the project owner or project manager. See 
budget reserve. 


matrix Any organisational structure in which the 
project. manager shares responsibility with the functional 
managers for assigning priorities and for directing the 
work of individuals assigned to the project. 


maturity model 
management practices against others in the same 
industry and to guide and continuously strive to improve 
the management of projects. Most maturity models 
recognise levels of maturity so organisations can gauge 
their relative maturity against others in their industry. 


A model used to assess project 


mentor Typically a more experienced manager who 
acts as a personal coach and champions a person's 
ambitions. 


merge activity An activity that has more than one 
activity immediately preceding it. 


milestone An event that represents significant, identifiable 
accomplishment toward the project’s completion. 


mission A mission statement is a statement of the 


purpose of a company, essentially its reason for existing. 


mitigating risk Action taken to either reduce the 
likelihood that a risk will occur and/or the impact the risk 
will have on the project. 


mitigation strategy (risk response) The types of 
strategies that can be applied to identified risks in order 
to reduce, eliminate (or accept) risks prior to project 
start-up or during the Planning and Execution phases of 
the project. 


Monte Carlo technique (simulation) A method of 

simulating project activity durations using probabilities. 
The method identifies the percentage of times, activities, 
and paths that are critical over thousands of simulations. 


N 


negative reinforcement A motivational technique 
in which negative stimuli are removed once desired 
behaviour is exhibited. 


Net Present Value (NPV) A minimum desired rate of 
return discount (e.g., 15 per cent) is used to compute 
present value of all future cash inflows and outflows. 


network A logic diagram arranged in a prescribed 
format. (e.g., A@A or A®N) consisting of activities, 
sequences, interrelationships, and dependencies. 
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network organisation An alliance of several 
organisations created for the purpose of creating 


products and services for customers. 


network sensitivity The likelihood that the critical path 
will change on a project. 


Nominal Group Technique (NGT) A structured problem- 
solving process in which members privately rank-order 
preferred solutions. 


fe) 


objective An end you seek to create or acquire. Should 
be specific, measurable, realistic, assignable, and include 
a time frame for accomplishment. 


open tender A tender which is open to the marketplace 
where any suitable supplier can respond to the tender. See 
also closed tender. 


opportunity risk An under-used but understood 
aspect of risk management where opportunity risks are 
identified and tracked in addition to the normal threat 
risks. 


Organisation Breakdown Structure (OBS) A structure 


used to assign responsibility for work packages. 


organisational culture A system of shared norms, 
beliefs, values, and assumptions held by an organisation's 
members. 


organisational currencies A set of currencies used as 
a medium of exchange within organisations to influence 
behaviour. 


organisational politics 
of individuals to acquire, develop, and use power and 
other resources to obtain preferred outcomes when there 


Actions by individuals or groups 


is uncertainty or disagreement over choices. 


outcomes Project deliverables that are often behaviour- 
based. Delivering a software system may not be the 
measure of success. Belivery of a software system that 

is used by 90 per cent of employees for all financial 
transactions would be a desired deliverable. 


outputs Project deliverables that are associated with 
more tangible elements, such as a project which delivers 
a training manual, training system and process for the 
assessment of training needs. 


outsourcing Contracting for the use of external sources 
(skills) to assist in implementing a project. 


overhead costs Typically organisation costs that are 
not directly linked to a specific project. These costs cover 
general expenses such as upper management, legal, 


market promotion, and accounting. ®verhead costs are 


usually charged per unit of time or as a percentage of 
labour or material costs. 


oversight A setof principles and processes to guide 
and improve the management of projects. The intent is 
to ensure projects meet.the needs of the organisation 
through standards, procedures, accountability, efficient 
allocation of resources, and continuous improvement in 
the management. of projects. 


P 


padding estimates Adding a safety factor to a time 

or cost estimate to ensure the estimate is met. when the 
project is executed. Professional pro ject management. 
practice prefers the use of project contingencies instead 
of ‘artificially’ padding estimates of individual work 
packages. 


pair-wise criterion Pair-wise criterion is a technique of 
prioritising sets of criteria against. which projects and 
investments are selected or prioritized. See also AHP. 


parallel/sequence activities Activities which can occur 
simultaneously, i.e. they can partially or wholly overlap. 


Pareto chart A chart which supports the identification 
of 80 per cent of the problems/faults. @ften used in 

a quality control sense to identify categories where 

80 per cent of the faults/problems occur. 


Partnering charter A formal document that states 
common goals as well as cooperative procedures used to 
achieve these goals which is signed by all parties working 


ona project. 


path A sequence of connected activities. See also 


critical path. 


payback model The time it takes to pay back the 
project investment (investment/net annual savings). This 
method does not consider the time value of money or the 
life of the investment. 


performance review In general, all review methods of 
individual performance centre on the technical and social 
skills brought to the project and team. These reviews 
stress personal improvement and are frequently used for 
salary and promotion decisions. 


personal-related currencies Influence based on 
enhancing another person's self-esteem. 


PERT method/PERT simulation (Project Evaluation 
Review Technique) @ne of a number of tools used in the 
estimating of cost, time or resources based on a weighted 
average calculation of optimistic figure + 4 times the 
most likely figure + the pessimistic figure. The resulting 
number divided by 6 results in the PERT estimate. 


phase estimating 
macro estimate for the pro ject and then refines estimates 
for phases of the project as it is implemented. 


This estimating method begins with a 


Phase gating A structured process to review, evaluate, 
and document outcomes at each project phase and to 
provide management with information to guide resource 
deployment. toward strategic goals. 


phase project delivery 


project in phases instead of when the project is entirely 
completed. 


Belivering useful parts of a 


Plan, Do, Check, Act (PDCA) A simple quality technique 
often applied and associated with the life cycle of a project. 


planned value (PV) The planned time-phased baseline 
of the value of the work scheduled. Previously this was 
called budgeted cost of work scheduled (BCWS). 


portfolio A grouping of programs, projects and related 
operational work that delivers a greater set of benefits to 
the organisation when managed in a coordinated manner. 


portfolio management Centralised selection and 
management of a portfolio of projects to ensure that 
allocation of resources is directed and balanced toward 
the strategic focus of the organisation. 


Position-related currencies Influence based on the ability 
to enhance someone else’s position within an organisation. 


Positive synergy A characteristic of high-performance 
teams in which group performance is greater than the 
sum of individual contributions. 


power/interest grid A grid that allows the plotting 
of the power/interest of stakeholders on a project to 
ascertain their level of management. 


precedence diagram method A method used to 
construct a project network that uses nodes (e.g., a 
rectangle) to represent activities and connecting arrows 
to indicate dependencies. Also known as Activity-on- 
Node (A®N) diagrams. 


primary stakeholder A stakeholder who has a primary 
(or direct) interest in the outcomes and outputs of the 
project. See also secondary stakeholder. 


PRINCE2® An established project management 
methodology that provides a strongly process-driven and 
role-based approach to the management of projects. 


principled negotiation A process of negotiation that 
aims to achieve win/win results. 


priority matrix A matrix that is set up before the project 
begins that. establishes which criterion among cost, time, 
and scope will be enhanced, constrained, or accepted. 
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priority system The process used to select projects. The 
system uses selected criteria for evaluating and selecting 
projects that are strongly linked to higher-level strategies 
and objectives. See also AHP and pair-wise criterion. 


priorityteam The group (sometimes the project office) 
responsible for selecting, overseeing, and updating 
project.priority selection criteria. 


probability (likelihood) Assessment of a risk of 
something occurring given a set of conditions. 


process charts/flow chart A method of capturing 
processes and procedures. See BPMN. 


procurement See contractor and supplier evaluation. 


product backlog A prioritised list of project 
requirements with estimated time to turn them into 
complete product. functionality. 


product owner The person responsible for managing 
the product backlog in Scrum so as to maximise the 
value of the project. The product owner represents all 
stakeholders. 


program A collection of related projects, grouped in 
order to be managed in a more efficient manner. Usually 
delivers greater benefits to the organisation than each 
project would individually. 


project A temporary endeavour undertaken to create a 
unique product, service, or result. 


project audit report A report that includes classification 
of the project, analysis of information gathered, 
recommendations, lessons learned, and an appendix of 
backup information. 


project change/variation management systems A 
process that describes in detail exactly how project 
change/variations are to be logged, ranked, assessed, 
approved (or not) and funded. The change/variation 
process is typically documented in the scope management 
plan where not provided by the organisation’s PM®. 


project charter A document that authorises the project. 
manager to initiate and lead a project. 


projectclosure All of the activities of shutting down 
a project. The major activities are evaluation of project 
goals and performance, developing lessons learned, 
releasing resources and preparing a final report. 


project cost—duration graph A graph that plots project 
cost. against time; it includes direct, indirect, and total 
cost for a project over a relevant range of time. 


projectevaluation The process of assessing, verifying, 
and documenting project results. 
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project governance An important aspect of project. 
management. which formally documents how governance 
will take place, who is accountable for each decision and 
how the project will be managed. 


project interfaces The intersections between a project. 
and other groups of people both within and outside the 
organisation. 


projectised organisation A multi-project organisation 
in which project managers have full authority to assign 
priorities and direct the work of persons assigned to their 
project. 


Projectitis A social phenomenon in which project 
members exhibit. inappropriately intense loyalty to the 
project. 


project kick off meetin 
the project team. 


Typically the first meeting of 


project life cycle The stages found in all PMBoK based 
projects— Initiation, Planning, Executing, Closing and 
Monitoring & Controlling. 


project management The application of knowledge, 
skills, tools, and techniques to project activities to meet 
the project requirements. 


Project Management Body of Knowledge (PMBoK) The 
body of knowledge produced by the Project. Management 
Institute (PMI) that provides an industry standard, best 
practice approach to the management of projects. 


Project Management Institute (PMI) The recognised 
global project management body of project management 
practitioners. Also the governing body behind the Project 
Management. Body of Knowledge. 


Project Management Office (PM A centralised unit 
within an organisation that oversees and improves the 
management. of projects. @ften provides standards, 
process, templates and knowledge to assist project 


managers. 


Project Management Plan (PMP) The key document/s 
produced in the Planning phase of the project. life cycle. 
The PMP usually covers the ten areas of knowledge 
within the Project Management. Body of Knowledge 
(Scope, Time, Quality, Cost, HR, Communications, Risk, 
Procurement, Stakeholders and Integration). 


Project Management Professional (PMP) An individual 
who has met specific education and experience 
requirements set. forth by the Project Management 
Institute, has agreed to adhere to a code of professional 
conduct, and passed and examination designed to 
objectively assess and measure project management. 
knowledge. In addition, a PMP must satisfy continuing 
certification requirements or lose the certification. 


project manager The individual responsible for 


managing a project. 


project organisation An organisational structure in 
which core work is accomplished by project. teams. 


project partnering 
transforming contractual relationships into a cohesive, 


Anonbinding method of 


cooperative project team with a single set. of goals and 
established procedures for resolving disputes in a timely 
manner. 


Project Portfolio Management (PPM) systems The 
concept of managing a coordinated set of projects as a 
program or portfolio to deliver a greater set of benefits to 
the organisation than individual projects. 


Project screening matrix A matrix used to assess and 
compare the relative value of projects being considered 
for implementation. 


project sponsor 
champions and supports a project. 


Typically a high-ranking manager who 


project vision An image of what the project will 
accomplish. See also elevator pitch. 


Q 


Quality Assurance (QA) The criteria (standards) which 
define in a measurable manner that Quality that is to be 
achieved by the project. and of the products and services 
produced by the project. 


Quality Control (QC) The task of ensuring (monitoring) 
the project QA criteria to ensure that Quality is being 
delivered by the project. 


Quality Management Plan The document. which 
captures the QA and QC planning aspects of Quality 
on the project. This would include the standards being 
applied, how these are going to be controlled, roles and 
governance around Quality. 


R 
range estimating Reviewing risk against a possible 
range of estimates, to make estimating decisions. 


ratio (parametric) methods Uses the ratio of past actual 
costs for similar work to estimate the cost. for a potential 
project. This macro method of forecasting cost does not 
provide a sound basis for project. cost control since it 
does not recognise differences among projects. 


relationship-related currencies Influence based on 
friendship. 


Request for Information (RFI) A less formal information 
gathering tender type that the project can use to solicit. 
interest in a tender item. 


Request for Proposal (RFP) 
problem to solve is outlined and tenders respond with 
their (often unique) solutions. @ften used instead of RTF. 


A type of tender where the 


Request for Quote (RFQ) Sits between a RFI and RFT to 
obtain a quote on a tender requirements. 


Request for Tender (RFT) A type of tender where the 
project specifies exactly what the tenderer is expected to 
provide details of. 


resource Any person, groups, skill, equipment or material 
used to accomplish a task, work package, or activity. 


resource-constrained project A project that assumes 
resources are limited (fixed) and therefore time is 
variable. 


resource-constrained scheduling A technique that can 
be applied to a schedule where resources are constrained 
and other aspects of scheduling an activity might have to 
take place. 


resource matrix A matrix which records and then 
enables the subsequent analysis of resources to be used 


by the project. 


resource profil A chart showing the usage of a 
resource ina project over time. It is common to try to 
reduce the peak of the resource usage by leveling or 
smoothing, thereby improving the utilisation of the 
resource. 


resource smoothing A technique used to review how 
resources are used across a project and check for over 
(or under) allocation of a resource. 


responsibility matrix A matrix whose intersection 
point shows the relationship between an activity (work 
package) and the person/group responsible for its 


completion. 


retrospective A methodology that analyses a past 
project event to determine what worked and what didn't, 
develops lessons learned, and creates an action plan that 
ensures lessons learned are used to improve management 
of future projects. 


Revised Estimated Cost to Complete (ETCre) Estimated 
total cost based on revised estimates made by experts 
and actual costs to date. 


risk The potential for an undesirable event to occur. 


risk analysis (or risk evaluation) 
identified risks. 


The step of analysing 


Risk Breakdown Structure (RBS) 
(brainstorm) risks against categories of risk. Categories 
of risk could include financial, environmental, reputation 


A tool used to identify 


and safety. 
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tisk context The context of risk at the business level 
and within the project. Does the organisation have a high 
or low tolerance to risk-taking and how does this apply to 
the project environment? 


risk identificatio The process and tools used to 


exhaustively identifying possible risks to the project. 


Risk Management Plan (RMP) Part of the PMP defining 
the risk management approach and context, including 
any frameworks and methodologies which are to be 
applied to the project environment. 


risk monitoring and review The process of monitoring 
risks on an ongoing basis to assess changes to the 
residual risk status and monitor for any new risks which 
emerge as the project progresses. 


risk profil A list. of questions that. addresses traditional 
areas of uncertainty on a project. 


Risk Register The register to capture identified risks 
and the subsequent analysis of the risks. Used as a 
tracking tool during the monitoring and controlling of the 
project. 


risk severity matrix 
risks on a project. 


A tool used to assess the impact of 


rolling wave planning or iterative planning The concept 
of planning for the near term in detail and medium to 
long term at a higher level. 


root cause analysis A tool used to brainstorm and 
analyse the root cause of a problem. 


run chart A type of chart used to display (typically) 
quality control data in order that trends and patterns can 
be identified for further analysis. 
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sacred cow A project that is a favourite of a powerful 
management figure who is usually the champion for the 
project. 


scaling Adapting Agile PM to large, multi-team projects. 


scenario planning A structured process of thinking 
about future possible environments that would have 
potential high impact to disrupt the way you do business, 
and then developing potential strategies to compete in 
these altered environments. 


Schedule Performance Index (SPI) The ratio of work 
performed to work scheduled (EV/PV). 


schedule variance (SV) The difference between the 
planned dollar value of the work actually completed and 
the value of the work scheduled to be completed at a 
given point in time (SV = EV — PV). Schedule variance 
contains no critical path information. 
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scope creep The tendency for the scope of a project to 
expand once it has started. 


Scope document The key output of the Initiation phase 
of the project where all the dimensions of the project are 
defined and agreed. 


Scope Management Plan The management plan 
which documents the more static elements of scope 
management in a project environment. Included within 
the scope management plan would be: governance and 
approval of scope; the project change/variation process; 
issue escalation process; and deliverable acceptance 
process. 


Scrum An incremental, iterative development approach 
to managing projects with a well-defined set of roles and 
processes. 


Scrum master The person responsible for the Scrum 


process and its correct application. 


secondary stakeholder Stakeholders which may be 
indirectly interested or affected by the project. See also 
primary stakeholder. 


self-organising team A semi-autonomous team that. 
manages itself. 


sender-receiver model A documented model of 
communication and the effects to consider in sending and 


receiving a communication. 


sensitivity (of anetwork) The likelihood that the 
critical path(s) will change once the project begins to be 
implemented. 


sharing risk Allocating proportions of risk to different 
parties. 


six essential elements of a contract The ‘legal’ elements 
of a contract under Australian contract law that must 
exist for a contract to be considered binding. 


Six Sigma A quality methodology based around process 
improvement and the measurement of defects. 


slack (SL) Time an activity can be delayed before it 
becomes critical. 


SMARTA A term applied to the writing of project 
objectives: Specific, Measurable, Assignable, Realistic, 
Time-bound and Agreed. 


SMCR model (Berlo’s model) 
for the variety of human variables present in person-to- 
person communications: Source, Message, Channel and 
Receiver. 


A model that accounts 


social network building The process of identifying and 
building cooperative relationships with key people. 


sociotechnical perspective A focus on the interaction 
between tools/methods and people. 


splitting A scheduling technique in which work is 
interrupted on one activity and the resource is assigned 
to another activity for a period of time, then reassigned to 
work on the original activity. 


sprint A fixed period of time during which a Scrum 
teams works to twn the product backlog it has selected 
into an increment of product functionality. 


sprint backlog A list of tasks that defines a Scrum team's 
work for a sprint. Each task identifies those responsible 
for doing the work and the estimated amount of work 
remaining on the task on any given day during the sprint. 


sprint planning meeting A Scrum meeting divided into 
two segments. During the first segment the product owner 
presents the highest. priority product. backlog to the team. 
The team and product owner collaborate to determine how 
much of the product backlog it can turn into functionality 
during the upcoming sprint. Buring the second segment, 
the team plans how it will meet. his commitment. by 
detailing its work as a plan in the sprint. backlog. 


sprint retrospective meeting AScrum meeting in 
which the team discusses the just concluded sprint and 
determines what could be changed that might make the 
next sprint more enjoyable and productive. 


sprint review meeting A Scrum meeting in which the 
team demonstrates to the product owner and any other 
interested parties what it. was able to accomplish during 
the sprint. 


stakeholder Individuals and organisations that are 
actively involved in the project, or whose interests may 
be positively or negatively affected as a result of project 
execution or completion. They may also exert influence 


over the project and its results. 


stakeholder matrix A matrix used to capture and 
analyse stakeholder information. 


stakeholders Individuals and organisations that are 
actively involved in the project, or whose interests may 
be positively or negatively affected as a result of project. 
execution or completion. They may also exert influence 
over the project and its results. 


start-to-start (SS) relationship Where a successor 
activity can start at the same time (or any time after) a 
predecessor activity. 


Statement of Work (SoW) @ften-used terminology 
that is comparable to a Scope document. See also Scope 
document. 


strategic objectives 
to describe at a strategic level the key objectives of their 
focus for a period of time. 


The statements organisations use 


strategic planning The process that captures the 
strategic planning activities of an organisation, who 
is accountable, and the timeline for the events to 
take place. 


strong matrix A matrix structure in which the project. 
manager has primary control over project activities and 
functional managers support project work. 


Subject Matter Expert (SME) A stakeholder to the 
project who is an expert in their field. 


Subject Matter Expert (SME) A stakeholder to the 
project who is an expert in their field. 


systems thinking A holistic approach to viewing 
processes that emphasises understanding the interactions 
among different processes — as opposed to viewing 
processes as independent activities. 


T 


task-related currencies Influence based, helping 
someone else do their work. 


team building A process designed to improve the 
performance of a team. 


team charter A charter between members of the project 
team, including a motivational and value-based statement. 


which the team agrees to abide by. 


team evaluation Evaluating the performance of the 
project team using a minimum core of conditions in 
place before the project. began. Evaluation practices 
should emphasise the team as a whole, while minimising 
individual performance. 


team rituals Ceremonial actions that reinforce team 
identity and values. 


template method Use of a prepared form to develop 
project networks, costs, and time estimates. 


tender process The process often defined within 
the organisation’s process assets that outlines the 
steps/stages all tenders must progress through in 
order to comply with organisational governance 
requirements. 


The 4C’s of Truth about Communication A tool 

that assists in the development of a communication 
message: Comprehension, Credibility, Connection and 
Contagiousness. 
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the triple constraints Managing the interplay of scope, 
time and cost while trying to balance the performance 
(Quality) aspects of the project. 


threat risk A type of risk which has the potential to 
harm the project. 


time and cost databases Collection of actual versus 
estimated times and costs of work packages over many 
projects that are used for estimating new project tasks 
and their expected possible error. 


time buffe A contingency amount of time for an 
activity to cover uncertainty—for example, availability 


of a key resource or merge event. 


time-constrained project A project that. assumes 
time is fixed and, if resources are needed, they will 
be added. 


time-phased baseline A cost baseline that is derived 
from the WBS and project schedule. The budgeted costs 
are distributed to mirror the project schedule. 


time-phased budget Planned costs that are broken 
down by distinct time periods (e.g., $5,000 per week) for 
a work package, as opposed toa budget for a whole job/ 
project (6 months for a total of $130 000). Time phasing 
allows better cost control by measuring the actual rate 
of expenditure versus the planned expenditure rate over 
small pieces of the project. 


To Complete Performance Index (TCPI) the estimate 
of cost performance required by the project to meet the 
project's budget. goal. 


Total Quality Management (TQM) A philosophy of 
Quality where everyone in the creation or consumption of 
a product or service has a responsibility to its continuous 
improvement. 


total slack (TS) The amount of time an activity 
can be delayed and not affect the project duration 
(TS = LS — ES or LF — EF). 


tracking Gantt chart A Gantt chart that compares 
planned versus actual schedule information. 


Training Needs Analysis (TNA) An analysis of the skills 
and training required for resources identified by the 
project. 

transferring risk Shifting responsibility for a risk to 


another party. 


triple constraint 
cost, and scope. These constraints frequently represent 
trade-off decisions to be dealt with by the project 


The competing demands of time, 


manager and/or sponsor. 


GLOSSARY 


top-downestimates Rough estimates that use 
surrogates to estimate project time and cost (also called 
macro estimates). 


Vv 


variance Difference between two values (planned and 
actual for example), often applied to cost variance — the 
difference between what was planned to be spent and 
what was actually spent. 


Variance at Completion (VAC) Indicates expected 
actual cost over- or underrun at completion 
(VAC = BAC — EAC). 


Vision See project vision 


virtual project team Spatially separated project team 


whose members are unable to communicate face to face. 


Communication is usually by electronic means. 


vocational education and training (VET) The part of 
tertiary education and training system which provides 
accredited training in job-related and technical skills. 


For further information, also see: 


e =https:www.pmiorg/pmbok-guide-standards/lexicon 
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weak matrix A matrix structure in which functional 
managers have primary control over project. activities 
and the project manager coordinates project work. 


Work Breakdown Structure (WBS) A hierarchical 
method that successively subdivides the work of the 
project into smaller detail. 


WBS dictionary A database of WBS elements that 

is built as a resulting of creating a WBS across often 
multiple projects. Encourages the re-use of WBS items 
and the storing of estimate information so that lessons 
learned across similar projects can be captured. 


work package A task at the lowest level of the WBS. 
Responsibility for the package should be assigned 

to one person and, if possible, limited to 40 hours 

of work. 


wrap-up activities Activities associated with the closing 
down of a phase or stage of a project. 


. httpşs//www.smartsheet.com/complete-glossary-project-management-terminology 


e https:/www.scrum.org/resources/scrum-glossary 
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